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Abstract 

We consider the problem of mechanically constructing abstract machines from operational semantics, 
producing intermediate-level specifications of evaluators guaranteed to be correct with respect to the 
operational semantics. We construct these machines by repeatedly applying correctness-preserving 
transformations to operational semantics until the resulting specifications have the form of abstract machines. 
Though not automatable in general, this approach to constructing machine implementations can be 
mechanized, providing machine-verified correctness proofs. As examples we present the transformation of 
specifications for both call-by-name and call-by- value evaluation of the untyped Vcalculus into abstract 
machines that implement such evaluation strategies. We also present extensions to the call-by-value machine 
for a language containing constructs for recursion, conditionals, concrete data types, and built-in functions. In 
all cases, the correctness of the derived abstract machines follows from the (generally transparent) correctness 
of the initial operational semantic specification and the correctness of the transformations applied. 
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We consider the problem of mechanically constructing abstract machines from 
operational semantics, producing intermediate-level specifications of evaluators 
guaranteed to be correct with respect to the operational semantics. We construct these 
machines by repeatedly applying correctness-preserving transformations to operational 
semantics until the resulting specifications have the form of abstract machines. Though 
not automatable in general, this approach to constructing machine implementations can 
be mechanized, providing machine-verified correctness proofs. As examples we present 
the transformation of specifications for both call-by-name and call-by-value evaluation of 
the untyped A-calculus into abstract machines that implement such evaluation strategies. 
We also present extensions to the call-by-value machine for a language containing 
constructs for recursion, conditionals, concrete data types, and built-in functions. In all 
cases, the correctness of the derived abstract machines follows from the (generally 
transparent) correctness of the initial operational semantic specification and the 
correctness of the transformations applied. 



1. Introduction 

The correctness of programming language implementations is an important issue con- 
fronting language designers and implementors. Traditionally, such implementations are 
first built "by hand" and only then proved correct. Unfortunately, the resulting imple- 
mentations may have little relationship to the language's semantic specifications and so 
correctness may be difficult to show. For realistic languages, such correctness proofs 
become unwieldy because of the overwhelming amount of implementation-level informa- 
tion that must be correlated. In an alternative approach, a language implementation 
is constructed from the semantic specification in such a way that the resulting imple- 
mentation is guaranteed to satisfy correctness requirements: no independent proof being 
necessary. This approach may provide a mechanical, if not automatic, process allowing 
the correctness to be machine checked. This latter point is important when considering 
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the sizes of correctness proofs for realistic languages. Of course the choice of semantic 
specification and target language greatly influences the practicality of this approach. 

We use operational semantics to specify the meaning of programs and abstract ma- 
chines to provide an intermediate representation of the language's implementation. Op- 
erational semantics can be presented as inference rules or, equivalently, as formulas in 
a weak meta-logic permitting quantification at first-order and second-order types. Such 
semantic specifications provide high-level and clear descriptions of programming lan- 
guages, often handling numerous syntactic details in a declarative and simple fashion. 
Abstract machines can be presented as rewrite rules describing single-step operations on 
the state of a computation. Such specifications provide an intermediate level of represen- 
tation for many practical implementations of programming languages. The construction 
of abstract machines has traditionally been performed by hand, with correctness proofs 
following later. We demonstrate how to take a specification for an evaluator in the high- 
level, flexible style of operational semantics and derive, through formally justifiable steps, 
an abstract machine that implements that evaluator. While providing a direct proof of 
the correctness of derived abstract machines, these derivations also provide guidance for 
extending such machines and illustrate relationships among various abstract machines. 

Because operational semantics specifications can have rich structure, completely au- 
tomatic methods for constructing abstract machines from them seem feasible only for 
restricted classes of operational semantics. While identifying these classes and the corre- 
sponding procedures for constructing machines is of interest, we focus only on a general 
strategy for constructing machines and provide two examples of this task. Applying our 
approach to wider classes of languages and machines than considered here (for example, 
imperative languages and machines using a continuation-passing style) requires finding 
new transformations that will most certainly be dependent upon the particular struc- 
ture of the semantic specification and machine for each case. The examples presented, 
however, demonstrate the kind of reasoning required for simple functional languages and 
environment-based abstract machines, and suggest the feasibility of similar transforma- 
tions for other languages and architectures. 

The basic goal of the derivations described in this paper differs slightly from the prin- 
cipal goal of most program translations. Typical translations involve rewriting programs 
in a source language into a different, target language. Compilation is such a process. 
Our specifications of both operational semantics and abstract machines sit inside a sin- 
gle meta-logic. Most of our effort in transforming specifications attempts to make various 
aspects of computation that are implicit in the way one specification relies on this meta- 
logic explicit within another specification. In this way, transformed specifications rely less 
on the meta-logic. For example, one set of transformations changes a specification that 
uses second-order quantification to a specification that only uses first-order quantifica- 
tion. By continuing this kind of transformation, it is possible to reduce the specification's 
reliance on the meta-logic to a point where theorem proving using that specification can 
be done by a simple rewriting of computation states that is modeled well using abstract 
machines. 

This paper is organized as follows. In Section 2 we give a general description of the 
classes of operational semantics and abstract machines that we consider in later sections. 
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In Section 3 we present the meta-logic in which we specify operational semantics. This 
meta-logic provides various high-level features for simple manipulation of bound vari- 
ables and contexts. In Section 4 we present two high-level and declarative specifications 
of evaluators which use second-order quantification, and then we transform them into 
specifications using only first-order quantification. Included in this section is a treatment 
of the translation from terms represented in a simply typed A-calculus (with second-order 
constants) to terms in a language using only first-order constants. In Section 5 we take 
the first-order specifications developed in Section 4 and apply appropriate transforma- 
tions to them until we produce systems describing abstract machines. The resulting 
proof systems are equivalent to the Krivine machine [Cur90] (for the call-by-name case) 
and a variant of the SECD machine [Lan64] (for the call-by-value case). In Section 6 we 
describe how the derivations of Sections 4 and 5 can be modified or extended to yield 
machines for richer languages that include recursion, a conditional and other new lan- 
guage features. Finally, in Section 7 we discuss relations to other work, and in Section 8 
we summarize our results. 



2. Operational Semantics and Abstract Machines 

A recent trend in programming language design has been the use of operational se- 
mantics to define the semantics of a programming language. The particular style of 
operational semantics we consider here was inspired by Martin-L6f [Mar84] and uses 
sets of inference rules as specifications. Various instances of this approach have been 
called Proof- Theoretic Semantics, Natural Semantics and Relational Semantics [Han90, 
Kah87, MTH90]. This style of semantics has proved well suited to specifying evaluation 
strategies for realistic programming languages. Direct implementations of operational se- 
mantics require several general, symbolic techniques that are generally found in theorem 
provers or logic programming languages. 

Abstract machines have been effectively used as intermediate and low-level architec- 
tures suitable for supporting serious implementations of a wide variety of programming 
languages, including imperative, functional, and logic programming languages. Abstract 
machines are distinguished from operational semantics by having simple and direct algo- 
rithmic implementations that can employ efficient data structures. On the other hand, 
abstract machines are distinguished from lower- level, machine-code implementations be- 
cause typically the former uses pattern matching for destructing data while the latter 
explicitly addresses the notions of structure sharing, storage allocation, and register al- 
location. 

One goal of this paper is to connect these two methods of specifying the evaluation 
of programming languages and, in doing so, to provide means of producing abstract 
machines from operational semantics. Below we provide an overview of each of these 
paradigms. 
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2.1. Operational Semantics 

The phrase "structural operational semantics" is attributed to Plotkin, based on his 
seminal paper "A Structural Approach to Operational Semantics" [PI08I]. Although 
that term has come to describe a few different styles of specifications, in that paper it 
is used to describe evaluation in terms of a one-step reduction relation and his inference 
rules axiomatize this relation. Martin- Lof uses an operational semantics for describing 
type theory [Mar85). While he does not present the definition as a set of inference rules, 
his notion of evaluation is both compositional and syntax directed. Milner is perhaps the 
first to use inference rules to axiomatize evaluation to canonical form in his descriptions 
of the dynamic semantics of Standard ML, including the latest specification of the full 
language [MTH90]. 

The work presented here was initially inspired by the work in Natural Semantics, 
as described in [Kah87]. That work uses a first-order meta-logic with inference rules 
presented using sequents. We extend this work by using a higher-order (and higher-level) 
meta-logic employing less explicit, natural deduction-style inference rules. As a reference 
point we present a simple example of natural semantics, namely type inference for a 
simple functional language containing function abstraction and application. We begin 
by defining a first-order abstract syntax for the language. We introduce three constants 
var: string —>• terra, lam: (string x term) —►term, and com: {term x term) — ► term for 
constructing variables, A-abstractions, and applications (combinations), respectively. For 
example, we represent the familiar combinators I, K and S as follows: 



Concrete Syntax 


Abstract Syntax 


Xx.x 
XxXy.x 

XxXyXz.xz(yz) 


lam("x", var("x")) 
lam("x", lam("y", var("x"))) 
lam("x", lam("y", lam("z", 
com( com(var( "x" ),var( "z" )), 
com(var("y"),var("z" )))))) 



To specify type inference we must also represent types as objects and we can do this by 
introducing a new type ty and the constants tvar: string — ► ty and arrow: (ty x ty) — ► ty. 
The relationship between a program and its type is denoted by the predicate of the meta- 
logic hastype of meta-logic type (((string x ty) list) x term x ty) — > o. (Following Church 
[Chu40], we use o to denote the type of meta-logic propositions). The first argument of 
hastype is a context binding variable names to types. For example, the proposition 

hastype(nil, lam( "i" , var("i" )), arrow(tvar( "a"), tvar("a"))) 

relates the combinator I to its type. (List constructors are nil and the infix symbol 
::.) We axiomatize such propositions via the set of inference rules in Figure 1. The 
member predicate is assumed to be defined such that if member((JT,T), T) is provable 
then (X, T) is the leftmost pair in T in which the left component is X. If the proposition 



From Operational Semantics to Abstract Machines 5 

member((.y,r), T) hastype((X, S) :: T, M, T) 

hastype(r, var(X), T) hastype(r, lam(X,M), arrow(S.T)) 

hastype(r, M, arrow(S,r)) hastype(r, N, S) 

hastype(r, com(M,N), T) 

Fig. 1. Axiomization of type inference 

hastype(7, t, r) is provable using this set of rules then the term (encoded by) t has type 
(encoded by) r, given the assumptions in y for the types of free object- variables of t. 

In this setting and in others, the phrase "operational semantics" can be a misnomer, 
because such semantic specifications may lack a clear operational or algorithmic imple- 
mentation. The term deductive semantics is more accurate, as the meanings of semantic 
judgments are given by deductions; the task of theorem proving or proof construction is 
left unspecified. One focus of our paper is the systematic restructuring of specifications 
so that rather simple algorithms can provide complete theorem provers. Because proofs 
in the meta-logic of semantic judgments describe the course of a computation, they will 
play a central role in justifying each restructuring of operational semantics. 

2.2. Abstract Machines 

Many abstract machines have much in common, and we define here the formal notion of 
Abstract Evaluation System (AES) that captures and abstracts some of this commonal- 
ity. We assume some familiarity with term rewriting, its terminology and the notion of 
computation in a rewriting system [HO80]. Recall that a term rewriting system is a pair 
(E, R) such that E is a signature and R is a set of directed equations {/< =3- f*j}< e r with 
U,ri £ Tz(X) and V(r,) C V(/,). Here, Ts(X) denotes the set of first-order terms with 
constants from the signature E and free variables from X, and V(t) denotes the set of 
free variables occurring in t. We restrict our attention to first-order systems, i.e., £ is a 
first-order signature, though this is not essential. 

Definition 1. An Abstract Evaluation System is a quadruple (E,R,p,S) such that the 
pair (E, R U {p}) is a term rewriting system, p is not a member of R, and SCR. 

Evaluation in an AES is a sequence of rewriting steps with the following restricted struc- 
ture. The first rewrite rule must be an instance of the p rule. This rule can be understood 
as "loading" the machine to an initial state given an input expression. The last rewrite 
step must be an instance of a rule in S: these rules denote the successful termination 
of the machine and can be understood as "unloading" the machine and producing the 
answer or final value. All other rules are from R. We also make the following significant 
restriction to the general notion of term rewriting: all rewriting rules must be applied to 
a term at its root. This restriction significantly simplifies the computational complexity 
of applying rewrite rules during evaluation in an AES. A term t 6 Ts(0) evaluates to 
the term s (with respect to the AES (E,i?, p, S)) if there is a series of rewriting rules 
satisfying the restrictions above that rewrites t into s. 
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Fig. 2. The Krivine machine (top) and SECD machine (bottom) 



In certain situations, it might be sensible to have a more restricted definition of AES. In 
particular, allowing only linear rewrite rules (rules whose left-hand sides have no repeated 
variables) simplifies an implementation of an AES by eliminating the need for a costly 
runtime equality check (to be certain that the duplicated variables are instantiated to 
the same term). Similarly, requiring an AES to be deterministic (that is, no two rewrite 
rules can be used on the same term) is also sensible, especially in the context of modeling 
evaluation of functional programs. We note that all the examples presented in this paper 
do, in fact, satisfy both of these additional restrictions. 

The SECD machine [Lan64] and Krivine machine [Cur90] are both AESs and variants 
of these are given in Figure 2. The syntax for A-terms uses de Bruijn notation with 

(infix) and A as the constructors for application and abstraction, respectively, and 
{E, M} denotes the closure of term M with environment E. The first rule given for each 
machine is the "load" rule or p of their AES description. The last rule given for each is 
the "unload" rule. (In each of these cases, the set S is a singleton.) The remaining rules 
are state transformation rules, each one moving the machine through a computation step. 

A state in the Krivine machine is a triple {E, M, S) in which E is an environment, M 
is a single term to be evaluated and S is a stack of arguments. A state in the SECD 
machine is a quadruple {S,E,C, D) in which S is a stack of computed values, E is an 
environment (here just a list of terms), C is a list of commands (terms to be evaluated) 
and D is a dump or saved state. The expression nth(n,E), used to access variables in 
an environment, is treated as a function that returns the n + 1 st element of the list E. 
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Although Landin's original description of the SECD machine used variables names, our 
use of de Bruijn numerals does not change the essential mechanism of that machine. 

3. The Meta-Language 

All specifications of evaluation given in this paper, whether high-level or low-level, can 
be given as formulas or as inference rules within a simple meta-logic. 

3.1. Types, Terms, and Formulas 

Let S be a finite, non-empty set of non-logical primitive types (sorts) and let o be the 
one logical primitive type, the type of formulas, (o is not a member of S.) A type is 
either o, a member of S, or a functional type r—+cr in which both t and cr are types. The 
function type constructor associates to the right: read T\ — * — ► T3 as T\ — ► (t^ — ► T3). 
The order of a type is the measure of how deeply function types are nested to the left: 

primitive types are of order 0 and the type Ti — * ► t„ — ♦ To, in which to is primitive 

and n > 0, is one greater than the maximum order of the types n, . . . , t„. 

The logical constants A (conjunction) and D (implication) have type o —* o —*■ o and 
the logical constant V r (universal quantification of type t) has type (r — ► o) — ► o, for 
every type r that does not contain o. A signature S is a finite set of typed, non-logical 
constants. We often enumerate signatures by listing their members as pairs, written a: r, 
in which a is a constant of type t. Although attaching a type in this way is redundant, 
it makes reading signatures easier. Occurrences of o are restricted in the types of non- 
logical constants: if a constant c in £ has type Ti — ► ► r n — ► t 0 , in which n > 0 and Tq 

is a primitive type, then the types T\, . . . , t„ may not contain o. If To is o then c is called 
a predicate symbol. A signature is n th -order if all its constants are of order n or less and 
at least one constant in it is of order n. Only first-order and second-order signatures are 
used in this paper. 

A constant or variable of type r is a term of type r. If t is a term of type r — ► cr and s 
is a term of type t, then the application (t s) is a term of type cr. Application associates 
to the left: read the expression (£1 ti as ((ti ti) ^3). Finally, if a; is a variable of type 
t and t is a term of type <r, then the abstraction Xx t is a term of type r — *a. The usual 
definition of free and bound variable occurrences are assumed as well as the notion of 
a-conversion . The logical constants A and D are written in the familiar infix form. The 
expression V T (Az t) is written simply as V T z t. A term of type o is a formula. When t 
and s are A-terms, the expression t = s denotes the mathematical proposition that t and 
s are a-convertible. 

For variable x and term s of the same type, t[s/x] denotes the operation of substituting 
s for all free occurrences of x in t, systematically changing bound variable names in t to 
avoid free variable capture. Besides the relation of a-conversion, terms are also related 
to other terms by the following rules of /?- and ^-conversions. 

• The term s /?-converts to the term s' if s contains a subformula occurrence of the 
form (Xx t)t' and s' arises from replacing that subformula occurrence with t[t'/x]. 
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• The term s ^-converts to the terra s' if s contains a subformula occurrence of the 
form Aar (t x), in which x is not free in t, and s' arises from replacing that subformula 
occurrence with t. 

The binary relation conv, denoting X-conversion, is defined so that t conv s if there is a 
list of terms ti, . . . ,t n , with n > 1, t equal to t\, s equal to t n , and for i = 1, . . . , n — 1, 
either U converts to £j+i or t,+i converts to t, by a, j3, or r) conversion. Expressions of 
the form Aa: (t x) are called jj-redexes (provided x is not free in t) while expressions of 
the form (Ax t)s are called /?-redexes. A term is in A-normal form if it contains no 0 or 
»f-redexes. Every term can be converted to a A-normal term, and that normal term is 
unique up to the name of bound variables. See [HS86] for a more complete discussion of 
these basic properties of the simply typed A-calculus. 

3.2. Specifications as Formulas 

Our specification of evaluators uses a weak extension to Horn clause logic. In particular, 
let syntactic variables A range over atomic formulas and B range over possibly universally 
quantified atomic formulas. Formulas used for specifications are closed formulas of the 
form 

Vzi . . . Vz m [(Bi A ... A B„) D A] (m,n> 0). 

(If n = 0 the implication is not written.) These formulas differ from Horn clauses 
only in that the 5,'s are not necessarily atomic: they may be universally quantified 
atomic formulas. Occurrences of such universal quantifiers are called embedded universal 
quantifier occurrences. The quantifier occurrences Vz f - are called outermost universal 
quantifier occurrences. 

A specification is a pair (E,V) in which S is a signature and V is a finite, non-empty 
set of these extended Horn clauses with the following restrictions. 

1 The signature S is exactly the set of non-logical constants with occurrences in for- 
mulas in V . Thus, E does not need to be listed separately. 

2 If a formula in V contains an embedded universal quantifier occurrence, then that 
quantifier occurrence binds a variable of primitive type and E is a second-order sig- 
nature. 

3 If E is first-order then all of the outermost quantifier occurrences in formulas in V 
bind variables of (non-logical) primitive type. In this case, the set V must contain 
just first-order Horn clauses; that is, they contain no embedded quantifiers. 

Such pairs (E,7>) are used to specify the extension to predicates that are members of 

E. In particular, if p : T\ — ► ► r n — > o is a member of E, then the tuple (f i , . . . , t n ) (f° r 

closed terms ti) is in the extension of p if and only if the closed formula (p ti ■ ■ ■ t„) is 
provable from V and all the constants in the terms t lt . . . ,t n are in E. Since the formulas 
permitted in specifications are so weak, classical logic provability here coincides with 
intuitionistic and minimal logic provability. In each of these cases, equality of terms and 
formulas is A-convertibility. 

For example, let S be the set {i} containing only one primitive type, let Eo be the 
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second-order signature 

{abs : (i — ► i) — + i, app : i — >• £ — »■ i, eval : i — ► i —>£>}, 

and let Po be the set containing the two formulas 

Vj-^m (et/ct? (a6s ro) (a&s ro)) 

V»pV t gV,t;V,_» t m (eua/ p (a6s m) A et>a/ (m q) v D eval (app p q) v). 

Untyped A-terms are represented using the constants abs (denoting abstraction) and app 
(denoting application). We discuss this syntax further in Section 4.1. This example has 
no embedded universal quantifier occurrences but it does have one outermost quantified 
variable whose type is of order 1. The specification (Eo)'Po) is used in Section 4 to give 
a high-level specification of call-by-name evaluation. 

For another example, let S = {i, not, list), and consider the second-order signature 

Si = {abs : (i —* i) — ► i, app : i — ► i — ► i, 0 : nat, 1 : ncrf, + : nat — ► not — ► nat, 
nil : list, :: : i — *■ list — ► list, count : list — ► i — > nat — ► o} 

and the set 7^ containing the four formulas 

VlUtNipVi<lVna.tcVnatd(count I p c A count I q d 3 count I (app p q) (1 + (c+ d))) 

'iiiitl^i-*i'rn^i^natc(yix(count (x :: I) (m x) c) D counf / (a6s ro) c) 

ViistlVi3:(count (x :: /) a; 0) 

ViistNixViyVnatc(count I x c D coimi (y :: /) a: c). 

(Here the list constructor :: is written in infix notation.) The pair (Si, "Pi) can be used to 
count the number of occurrences of the constant app in a term. In particular, if the atomic 
formula (count nil t n) is provable from V\ then n is an arithmetic expression equal to 
the number of occurrences of app in t. The functional interpretation of operations such 
as + are not part of the logic we have described here. For example, if there is a proof of 
the formula 

count nil (abs\x(abs\y(app (app x y) (app y *)))) n 

from Si and V\ then that proof contains a subproof of the formula 

count (d :: c :: nil) (app (app c d) (app d c)) n, 

where c and d are eigenvariables of the proof. Thus, eigenvariables can be used to name 
bound variables when it is important to "descend" through an abstraction. This latter 
formula is provable if and only if n is the expression 1 + (1 + (0 + 0) + (1 + (0 + 0))). 
Beyond this example, the most sophisticated integer computations we need are those for 
incrementing positive integers, and for that, special treatment of integers is not necessary. 
At first glance, it may appear that the first argument of count that lists free variables is 
not needed for this specification. It is only used to determine whether or not the term 
in the second argument of count is a variable. Given the specification of terms that we 
have picked, it is clear that a term is a variable if and only if it is not an app or an 
abs. Specifying such a negative condition, however, is not possible in this meta-logic, 
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and, hence, we are required to replace it with the positive condition of finding the second 
argument in the first argument. 



3.3. Specifications as Proof Systems 

Because of the simple structure of formulas in specifications we can describe specifications 
instead as proof systems by replacing formulas with inference rules. We view a clause of 
the form 

Vzi . . . Vz m [Si A .. . AB n D A] 
as an inference rule of the form 

Bi • •• B n 
A 

in which the universal quantifiers Vzi . . .Vz m are implicitly assumed. We use the con- 
vention that all capitalized letters occurring in formulas of inference rules are variables 
implicitly quantified by outermost universal quantifiers. The clauses specifying count 
above can be specified as the following set of inference rules. 



count L P C count L Q D 


Vix(count (x:: L) (M x) C) 


count L (app P Q) (1 + (C+D)) 


count L (abs M) C 




count L X C 


count (X :: L) X 0 


count (Y::L) X C 



Inference rules of this kind only explicitly mention one logical connective, universal 
quantification, and occurrences of it are permitted only in the premises of rules. Thus, to 
complete a proof system we must specify the introduction rule for the universal quantifier. 
This and the rule for A-conversion are 

B[y/X] V-l and A. 



Vz B B' 

These rules have the following provisos: for V-I, the eigenvariable y must not be in £ or 
free in Vx B; and for A, we must have B conv B'. Usual notions of natural deduction 
[Gen69, Pra65] are assumed. Since there are no implications to introduce, proofs here do 
not involve the discharging of assumptions. (Adding such occurrences of implication is 
natural and useful for a wide range of specifications [Han90]; such implications, however, 
play only a small role in the specification of evaluators and so are not considered here.) A 
proof system is first-order or second-order if its equivalent presentation as a specification 
(£, V) is such that £ is first-order or second-order, respectively. 

In the rest of this paper, we present specifications as inference rules. It is impor- 
tant to note, however, that proofs in classical (or intuitionistic or minimal) logic using 
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specifications-as-formulas are isomorphic to proofs using specifications-as-proof-systems. 
The choice of which presentation to use is only one of notational convenience. 



3-4- Abstract Evaluation Systems as Proof Systems 

While specifications form weak logical systems, they provide high-level mechanisms for 
the specification of evaluation in object-language functional programs. Many of these 
mechanisms, such as universal quantification, higher-order types, and A-conversion, do 
not correspond to anything that appears in abstract evaluation systems. The following 
restricted proof systems, however, do correspond to AESs. 

Definition 2. A set of first-order inference rules is AES-defining if there are two binary 
predicate symbols p and q (not necessarily distinct) such that 

• every axiom is of the form in which s and t are terms and V(t) C V(s): 

p s t ~ 

p t z 

• there is a distinguished inference rule of the form in which s and t are 

q s z 

terms, V(t) C V(s), and z is a variable not free in either s or t; and 

• inference rules that are neither axioms nor the distinguished rule are of the form 

^ * Z in which s and t are terms, V(t) C V(s), and z is a variable that is not free 
p s z 

in either s or t. 

For every AES-defining proof system 1 we can define an AES (£, R, p, S) (modulo the 
renaming of free variables) such that the following condition holds: for all terms s and 
t, T r- q s t if and only if there exists some AES-rewriting sequence s =i> s' =£• s" ==> t 
for some r £ S and some terms s' and s" (=> denotes zero or more rewritings using 
R-rules). The correspondence between some given I and (£, i?, p, S) can be described 
as follows: 

• I contains the axiom if and only if S contains the rewrite rule s => t : 

p s t 

p t z 

• J contains the distinguished rule if and only if p is s =J- 1: and 

q s z 

p t z 

• X contains the rule if and only if R contains s t. 

p s z 

One important characteristic of AES-defining proof systems is the use of an "output" 
variable in the inference rules. Every inference rule (other than the axioms) is either of 
p t z p t z 

the form or in which z is a variable (implicitly universally quantified). 

J) S % s z 

Thus, for every proof in such a proof system there is a single term which is the second 
argument for every formula occurrence in the proof. Obviously, most specifications of 
evaluators are not AES-defining proof systems. First-order specifications can fail to 
satisfy the requirements of AES-defining proof systems in a number of ways. Particular 
violations that concern us later are proof systems that contain inference rules with 

1 multiple formulas in their premises; 
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2 variables in their premises that do not also occur in their consequents; or 

p t y 

3 the form in which y and z are not the same variable or they occur in s or t. 

p s z 

We can systematically convert a proof system containing inference rules with multiple 
premises to an equivalent (modulo a simple relation between provable formulas) system 
containing only rules with at most one premise. The latter two cases, however, are more 
problematic and no single method appears universally applicable. 



3.5. Implementations of the Meta-Logic 

Meta-logical specifications can be interpreted as logic programs and the literature on 
implementing logic programs can be directly applied to provide implementations of spec- 
ifications. If a specification is first-order, then Prolog or the TYPOL language of the 
CENTAUR system [Kah87] can provide a depth-first interpreters of it. Since the higher- 
order logic programming language AProlog [NM88] supports higher-order quantification, 
A-conversion, and embedded universal quantification, it can be used to give a depth-first 
implementation of the full meta-logic. Although depth-first interpretation is not gener- 
ally complete, it is complete for those AES-defining proof systems that are deterministic 
(at most one rule can be applied at a given point in building a proof in a bottom-up fash- 
ion). Because almost all the AES-defining proof systems presented here are deterministic, 
AProlog can be used to provide correct implementations of them. Since such implemen- 
tations are also tail-recursive, the result of compiling them should be efficient, iterative 
programs. By translating the specifications in this paper into AProlog code, we have 
been able to experiment with them. We found such prototyping and experimentation 
valuable in understanding the dynamics of various specifications. 



4. From Explicit to Implicit Abstractions in Terms 

This section begins with the specification of call-by-name and call-by-value as proof 
systems using the approach described in Section 3.3. Our first specifications represent 
object-level, untyped A-terms using a meta-level syntax that employs simply typed A- 
terms over a second-order signature. This approach makes it possible to map object- 
level abstractions directly to meta-level abstractions. Since the elegant and declarative 
meta-level operations for handling explicit abstractions are available, specifications can 
be clear, concise, and suitably abstracted from numerous implementation details. As we 
plan to construct abstract machines that use only first-order terms to encode object-level 
programs, we must translate terms using a second-order signature in which A-abstractions 
are available explicitly to terms over a first-order signature in which abstractions are avail- 
able only implicitly. The task of changing the specification of evaluation to accommodate 
this change in term-level syntax is not trivial. This section shows how this change can 
be effected for call-by-name and call-by-value evaluation. 
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4-1. Specifying Two Evaluators 

In this section and the next, we only consider the untyped A-calculus since it is rich 
enough to illustrate several problems in the evaluation of functional program. In Section 6 
we consider several of those language extensions needed for more realistic functional 
programming languages, and demonstrate how our methods can be applied to those 
extensions. 

The untyped A-terms can be encoded into simply typed A-terms of base type tm using 
two constants abs : (tm — ► tm) — ► tm and app : tm — * tm — > tm, for encoding object-level 
abstraction and application, respectively. (A formal definition of the encoding and its 
various properties can be found in [Han90].) Some example terms in this syntax are 
listed below. 



Untyped A-terms 


Simply typed A-terms 


Xx.x 

Ay.y 

(\x.x)(Xy.y) 


(abs Xu.u) 

(Xz.z)(abs Xu.u) 

(app (abs Xu.u) (abs Xv.v)) 



All three untyped A-terms are /3-convertible, but only the first two are a-convertible. 
Only the first two simply typed A-terms are /^-convertible. By convention, we typically 
select the unique (up to a-conversion) simply typed A-term in /?»j-long normal form to 
represent the corresponding untyped A-term term. That is, although (abs Xu.u) and 
(Xz.z)(abs Xv.v) are equal meta-level terms and both encode Xx.x, we only refer to the 
/?»7-long normal term (the first one here) as the encoding of the given untyped A-term. 

We observe that a-equivalent terms in the untyped A-calculus map to A-convertible 
terms in the simply typed A-calculus of the meta-logic and a /3-redex in the untyped A- 
calculus maps to a meta-level term of the form (app (abs s) t), which is not a meta-level 
/?-redex. 

To demonstrate some simple computations using this encoding, consider the follow- 
ing two examples. First, to determine if two terms p, q : tm are representations of 
a-convertible untyped (object- level) A-terms, we only need to check if the equality p = q 
is provable in the meta-logic (such equality contains the meta-level conversion rules for 
a, /?, and rj). 

For the second example, consider specifying object-level substitution. This can be 
done with using the 3-place predicate subst.tm — ► tm — ► fm — ► o, which is axiomatized 
using the simple axiom 

V tm _ tm A V tm S (subst (abs A) B (AB)). 

Thus if s, t,u : tm are encodings of untyped terms Xx.p, q, r, respectively, and meta-level 
proposition (subst s t u) is an instance of the above axiom, then, at the object-level, r 
is a-convertible to the term p[q/x]. (See [Han90] for a proof of this correspondence). 

The two inference rules in Figure 3 specify call-by-name evaluation and the two in- 
ference rules in Figure 4 specify call-by-value evaluation. In both of these cases, values 
are A-terms in weak-head normal form. Rather than explicitly use the axiom for subst 
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eval P (abs M) eval (M Q) V 

eval (abs M) (abs M) eval (app P Q) V 

Fig. 3. High-level specification of call-by-name evaluation 

eval P (abs M) eval Q R eval (M R) V 

eval (abs M) (abs M) eval (app P Q) V 

Fig. 4. High-level specification of call- by- value evaluation 

described above, these evaluators use the meta-level expressions (M Q) and (MR), re- 
spectively, to specify substitution via meta-level /?-conversion. Alternatively, we could 
use the axiom for subst by expressing the rule for application (in the call-by-name case) 
as 

eval P (abs M) subst (abs M) Q R eval R V 
eval (app P Q) V 

Notice that these inference rules contain variables of the functional type tm — ► tm and 
no rule contains explicit mention of bound variables. If we name the rules in Figure 3 by 
€ , then S h eval s t if and only if t encodes the weak-head normal form (whnf ) obtained 
by a normal-order reduction of the untyped A-term encoded by s. A similar statement 
can be made for the call-by-value inference rules. 

These inference rules provide a high-level specification of evaluation in several senses. 
Below we focus on two of these senses, namely, the use of meta-level /?-conversion to 
automatically perform object-level substitution of terms for bound variables and the use 
of A-terms instead of simpler first-order terms in the meta- language. 

4-2. Introducing Closures into the Call-by-Name Evaluator 

To prepare for a change in the meta-level representation of untyped A-terms, we introduce 
three predicates isabs, isapp and apply into the call-by-name evaluator in order to move 
the actual representation of terms away from the clauses that directly describe evaluation. 
The resulting inference system is given in Figure 5. Notice that the constants abs and app 
do not occur in those inference rules that mention the eval predicate. Using elementary 
facts about unfolding of inferences rules, it is immediate that the eua/-facts provable 
from Figure 3 and from Figure 5 are identical. (A brief discussion of unfolding can be 
found in Appendix A.) 

We now introduce the new constant clo : tra— >(tra— ><ra)— >ira to "name" object-level 
/3-redexes. All meta-level terms containing clo are A-convertible to terms of the form 

(clo t\ Xxi(. . . (clo t n Xx n s) . . .)) (n > 0) (*) 

in which s is either (app si S2) for some Si and 52, (o-bs s 1 ) for some s', or one of the 
bound variables xi, . . . ,x n . Depending on these three cases, we say that (*) is the closure 
of an application, the closure of an abstraction, or the closure of a variable, respectively. 
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isapp A P Q 



eval P R 



apply Q R S 



eval S V 



eval A V 



isabs P 



eval P P 



isabs {abs M) 



isapp {app P Q) P Q 



apply Q (abs M) (M Q) 



Fig. 5. Addition of some meta-level predicates. 

Furthermore, all terms that appear in evaluators we consider have the additional property 
that the terms t lt . . . ,t n are all closed terms and hence contain no occurrences of the 
bound variables xi,. . ., x n . If n = 0 then (*) simply denotes s. Terms of the form (*) 
are abbreviated using the syntax (clo i Xx s). 

Let i be a term built from abs, app, and clo as described above. The term t° denotes 
the A-normal form of the result of replacing every occurrence of clo in t with the term 
XuXv (v u). This mapping replaces all named /?-redexes with meta-level /?-redexes, which 
are then removed in the process of forming the A-normal form. 

Since the rules for isabs, isapp, and apply in Figure 5 are sensitive to the particular 
structure of terms, these rules must be modified to handle terms containing clo. For 
example, rules for isabs and isapp must now determine whether terms are closures of 
abstractions and applications. Since terms can also be closures of variables, we intro- 
duce the isvar predicate to test for such terms and to return the term in the closure 
that corresponds to that variable. The rules listed in Figure 6 address this additional 
structure. 

As with the count example in Section 3.2, when reading the inference rules in Figure 6 
from the bottom to top, the eigenvariables introduced by universally quantified premises 
can be seen as naming the bound variables of the A-abstraction that they instantiate. 
Consider, for example, proving the formula 



If this atomic formula has a proof, that proof must also contain a subproof of the formula 



where s' is the result of replacing the bound variables x\ , . . . , x n in s with the (distinct) 
eigenvariables c% , . . . , c„ , respectively. The proof of this latter formula is essentially the 
computation that determines which of these eigenvariables is equal to s' and that t is the 
term associated with that eigenvariable. 

Let I-5 denote provability from the inference rules in Figure 5 and let l~6 denote prov- 
ability from the inference rules in Figure 6. The proof of the following lemma follows 
from inspection of the inference rules for the meta-level predicates isabs, isapp, isvar 
and apply given in Figure 6. 

Lemma 3. Let r be a term of type tm over the constants abs, app and clo. 



isvar nil (clo ti Xxi(. . . (clo t n Xx n s) . . .)) t. 



isvar ((c n ,t n ) (ci,ti) :: nil) s' t 



/. Hannan and D. Miller 



16 



isapp A P Q eval P R apply Q R S eval S V 

eval A V 

isabs P isvar nil P T eval T V 

eval P P eval P V 

(isabs (M x)) 
isabs (abs M) isabs (clo T M) 

Vz (isapp (A x) (M x) (N x)) 
isapp (app P Q) P Q isapp (clo T A) (clo T M) (clo T N) 

Vx (isvar ((x,T) :: E) (M x) V) isvar EXT 

isvar E (clo T M) V isvar ((X,T) :: E) X T isvar ((Y,S) :: E) X T 

Vx (apply Q (M x) (N x)) 
apply Q (abs M) (clo Q M) apply Q (clo T M) (clo T N) 

Fig. 6. Evaluation with closures represented using clo : tm — ► (tm — > im) — *• tm. 

1 He isabs r if and only if r is the closure of an abstraction. 

2 ("6 isapp r r\ T2 for r\ and t2 terms of type tm if and only if r is of the closure of 
an application, that is, it is of the form (clo t Xx (app z\ Z2)) for some terms Z\ and 
2 2 of type tm, in which case rj is (clo i Xx z\) and vi is (clo i Xx 22)- When this 
relationship holds, (app rj r°) -- r° . 

3 h 6 isvar nil r s if and only if r is the closure of a variable, that is, it has the form 

(clo ti Xxi(. . . (clo t n Xx n Xi) . . .)) (n > 1) 

for some i such that 1 < i < n. In this case, s is the term i,-. When this relation 
holds, s° = r°. 

4 1-6 apply t r s if and only if r is the closure of an abstraction, that is, it is of 
the form (clo u Xx (abs z)) for some term z of type tm — ► tm and s is of the form 
(clo u Xx (clo t z)). When this relationship holds, there is a term w of type tm —*tm 
such that r° = (abs w) and (w t°) convs 0 . In particular, f-5 apply t° r° s°. 

The following two propositions establish the correspondence between the proof systems 
in Figures 5 and 6. 

Proposition 4. Let t and r be two terms of type tm such that r° = t. If there is a 
term v such that r-5 eval t v, then there exists a term u such that u is the closure of an 
abstraction, f~6 eval r u, and u° = v. 

Proof. Let t and r be two terms of type tm such that r° = t, and assume that there 
is a term v such that (-5 eval t v. First, consider the case where r is the closure of a 
variable. By Lemma 3, \~e isvar nil r s where s is a proper subterm of r and s° — r°. 
Thus, if we can show that there exists a term u such that r~6 eval s u and u° = v, then 
we have l~6 eval r u via the proof rule for eval which has (isvar nil r s) as a premise. 
If s is still the closure of a variable, repeat this step again. This repetition terminates in 
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reducing r-6-provability of (eval r v) to hg-provability of (eval r' v) where r' is a proper 
subterm of r, (r')° = r°, and r' is the closure of an application or abstraction. 

Assuming that r is the closure of an application or abstraction, we can proceed by 
induction on the structure of proofs in Figure 5 of (eval t v). 

For the base case, assume that (eval t v) follows from the fact that t = v and h 5 isabs t. 
Thus r is the closure of a abstraction and by Lemma 3, l~6 isabs r, so h 6 eval r r. Thus, 
r is the promised value for u. 

For the inductive case, assume that (eval t v) follows from 

r-5 isapp 1 1\ ti, l~5 eval <i (abs w), r-5 apply £ 2 (abs w) s and r-5 eval s v. 

Since t is the term (app i\ ^2), it must be the case that r is the closure of an application. 
By Lemma 3, r-6 isapp r r\ r-x for some r\ and such that r\ = t\ and r!> = £2. By 
the inductive hypothesis, there is a «i such that = (abs w), u\ is the closure of an 
abstraction, and I- 6 eval r\ u\. By Lemma 3 there is a term z such that r-g apply r-z «i z 
and z° conv (w r%). Since s conv (w ^2), we have s conv z°. Using the inductive 
hypothesis again, we conclude that there is a w 2 such that h 6 eval z w 2 , «2 is the closure 
of an abstraction, and 1*2 = v. Thus, from 

he isapp r n r%, \~$ eval r\ u\, l~6 apply r 2 u\ z, and r-6 eval z 112, 

we can conclude that \-$ eval r v.2, which completes this proof. □ 

The following proposition establishes a converse to the preceding proposition. 

Proposition 5. Let r and u be two closed, A-terms such that \-§ eval r u. Then r-5 
eval r° w°. 

Proof. A proof of (eval r u) using Figure 6 can be converted directly to a proof of 
(eval r° u°) using Figure 5 by the following three steps. First, remove all proof rules 
above any formula occurrence whose head symbol is either the predicate isabs, isapp, or 
apply. Second, repeatedly remove instances of the inference rule for eval that has isvar 
in its premise by discarding the proof of its left premise and making the proof of the right 
premise the proof of the conclusion of that inference rule occurrence. Finally, replace 
every occurrence of a term t that is the argument of some predicate of some formula 
occurrence in the proof with the term t° . It is now an easy exercise to verify that the 
resulting proof is indeed a r-5-proof of (eval r° «°). □ 

The inference rules in Figure 6 successfully avoid performing substitution of terms 
for bound variables by making use of a closure-like structure. These rules still depend 
on using A-abstraction and universal quantification at the meta-level. We are now in a 
position to remove this dependency. 

A de Bruijn-style representation of terms containing clo can be built by introducing 
the first-order constant clo' . We treat indices in terms containing clo' in such a way that 
the second argument of clo' behaves as an abstraction. Consider the first-order signature 

{" : fotm — ► fotm — >■ fotm, A : fotm—* fotm, clo' : foim — ► fotm —* fotm, var : nat —*fotm}, 

where " denotes application, A denotes abstraction (this is an overloading of the A sym- 
bol), clo' denotes the closure construction, and var maps natural numbers into terms 
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encoding bound variables by their offsets. For the sake of brevity, we often abbreviate 
the term (var n) by n. Here, clo' treats its second argument as an abstraction by mod- 
ifying offsets of variables in that argument. Following [Bru72], closed terms of type tm 
can be placed in one-to-one correspondence with those terms of type fotm for which all 
indices denoting bound variables have an offset to an actual occurrence of a A or a clo'. 
Using this first-order signature, the A-term (clo t\ Xx\(. . . (clo t n Ax„ s) . . .)) translates 
to the first-order term (clo' t^ (. . . (clo' t' n s') . . .)) of type fotm, where t' lt . . . ,t' n , s' are 
the translations of t\, . . . , t n , s, respectively. An index i at the position of s denotes a 
variable to be replaced by the term t n -i ■ 

Since clo' is being used now to attach a list of terms ti,...,t n to the term s, clo' 
can be replaced with explicit lists; that is, the above term can be represented simply as 
{t' n :: - • ■::t' 1 ::nil, s'}. Of course, now an index of i at the position of s must be interpreted 
as referring to the i + 1 th member of the associated list of terms and the construction 
{., _} has type fotm list X fotm — ► fotm. For example, the term 

(clo (abs Xx.x) \u(clo (abs Xx(absXy y)) Xv(app v u))) 

would be translated to the term of type fotm {AAO :: AO :: nil, 0 " 1}. 

This final representation of syntax has several advantages over the one using clo or 
clo'. First, it involves first-order constants only. Second, simple pattern matching can 
determine if a term embedded in a closure is an abstraction, application, or variable 
index; recursing down a series of clo's is no longer needed. Third, the reversing of 
closures involved in proving isvar is not needed and the auxiliary list argument to isvar 
can be dropped. Finally, this syntax also makes it natural to identify a term s that is 
not a top-level {-,-} with {nil,s} and to identify the doubly nested closure expression 
{t, {t :: nil,s}} with simply {t :: I, s]. Given this change in the representation of terms, 
we can easily rewrite our inference rules to those presented in Figure 7. As in the 
transformation of the rules in Figure 5 and Figure 6, the only rules that change are those 
involved with the definition of the predicates isabs, isapp, isvar, and apply. 

If t is a term of type tm built from the constants abs, app, and clo, let t* be the 
corresponding de Bruijn-style representation of t of type fotm over the constants A, 
{_,_}, and var. The proof of the following proposition follows immediately from the 
motivation of the inference rules in Figure 7 given above. 

Proposition 6. Let t and v be two terms of type tm built from the constants abs, app, 
and clo. Then 1-6 eval t v if and only if \~r eval t* v* . 

Assuming that we are only interested in proving eua/-atoms, the inference rules in 
Figure 7 can be simplified, using unfolding transformations, to the inference rules Ma, 
which are displayed in Figure 8. These are further transformed in Section 5. 

4-3. Introducing Closures for Call-by-Value 

We can follow the approach above to construct a first-order specification of the call- 
by- value evaluator in Figure 4. Because the essential steps are the same as for the 
call-by-name case, with most of the rules in each system being the same, we present here 
only the different inference rules required for call-by-value evaluation. 
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isapp A P Q eval P R apply Q R S eval S V 

eval A V 

isabs P isvar P T eval T V 

eval P P eval P V 

isabs {E,XM} isapp {E,P'Q} {E,P} {E,Q} 

isvar {E, n} T 

isvar {T::E,0}T isvar {X :: E, n + 1} T 

apply Q {E,XM} {Q::E,M} 
Fig. 7. Evaluation using list structures for closures. 



eval {E,XM} {E,XM} 

eval {E,M} {E',XM'} eval {{E, N} :: E' , M'} V 
eval {E, M " N) V 

eval X V 
eval {X ::E,Q} V 

eval {E,n} V 
eval {X::E,n + l} V 

Fig. 8. The JVo proof system 

The first step in the section above introduces the new predicates isabs, isapp, and 
apply. The exact same modifications of proof systems can be done for the call-by-value 
case with the only difference being the rule for application: 

isapp A P Q eval P R eval Q S apply S RT eval T V 

eval A V 

The next step, which introduces the constant clo, follows as before, although the inference 
rule for evaluating closures of variables is now just 

isvar nil P V 
eval P V ' 

as no further evaluation is required. So the call-by-value version at this stage is just the 
set of rules in Figure 6, except for this rule and the rule for application, which is as above. 
The transition to a proof system that employs the first-order signature over type fotm 
follows as before, and all the rules are the same except the ones corresponding to the 



(A/o.l) 
(.Vo.2) 
(M>.3) 
(Mo A) 
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eval {E,XM} {E, XM} 



(Vo.l) 



eval {E, M} {E',XM'} 



eval {E,N} R eval {R::E',M'} V 



(Vo.2) 



eval {E,(M'N)} V 



eval {!::£,»} X 



(Vo.3) 



eval {E,n} V 



(Vc4) 



eval {X::E,n + l} V 



Fig. 9. The Vo proof system 

two rules noted above. Finally, when we unfold these rules to simplify their structure, 
we obtain the proof system Vo, displayed in Figure 9. 

5. Constructing Two Abstract Machines 

In this section we transform the two first-order evaluators listed at the end of Section 4 
into abstract machines. The transformation steps used in this section vary in generality: 
some apply to a wide range of inference rules specifying evaluation strategies while some 
are particular to a given evaluator. In all cases, however, transformations are motivated 
by two goals. The first goal is to continue making a specification less dependent on the 
meta-logic in which it is situated. For example, in the previous section, we replaced ex- 
plicit abstractions using simply typed A-terms with implicit abstractions using de Bruijn 
indices and first-order terms. Here we go further by eliminating, for example, any need 
for general (first-order) unification during proof construction. Our second goal is to 
commit to certain decisions left implicit or undetermined in a specification so that the 
resulting specification immediately yields an explicit algorithm. 

5.1. Constructing a Call-by-Name Machine 

We wish to convert the inference rules of system Afa (presented at the end of Section 4.2) 
to an AES-defining set of inference rules to obtain an abstract machine that implements 
(weak head) normal-order reduction for untyped A-terms. The proof rules in A/"o fail 
to be AES-defining for two reasons. First, proofs in Ao branch when an application is 
evaluated. Second, the rule for application has two variables, E' and M', in the premise 
that are not in the conclusion. The first problem is solved by a general technique; the 
second problem, however, seems to have no general solution. The bulk of this section 
describes a series of transformations to address this second problem. 

We first address the branching structure of proofs in AV Rule A r o-2 has two premises. 
During bottom-up proof construction, proofs for these two premises can be constructed 
in either order, or even in parallel. The choice is left to the particular implementation of 
the meta-logic. We can choose a sequential strategy and enforce its use by applying the 
following transformation. We introduce the new predicate symbol prove : (o list) — ► o 
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prove nil 
prove G 



prove (eval {E,XM} {E,\M})::G 

prove (eval {E,M} {£' ,XM'}) :: {eval {{E,N} :: E',M'} V) :: G 
prove (eval {E,M'N} V) ::G 

prove (eval X V) :: G 



prove (eval {X :: E,0] V)::G 
prove (eval {E,n} V) :: G 



prove (eval {X :: E, n + 1} V) :: G 
Fig. 10. The Wi proof system 

and the atomic axiom (prove nil). Each inference rule 

M---An . . prove A t :: ■ ■ • :: A n :: G 

ot J\i o is rewritten as 



(A/Vl) 
(JVi.2) 
(ATi.3) 
(ATiA) 
(Afi.5) 



A Q prove Aq :: G 

for variable G (of type (o list)) that is not free in any A{. This kind of transformation is 
applicable to any proof system in which all inference rules contain only atomic formulas 
as premises. In the case of A^o this transformation produces the new system Afi given in 
Figure 10. The argument to prove represents the collection of formulas that remain to 
be proved. This list behaves like a stack during bottom-up proof construction, with the 
first formula in this list always chosen as the next one to prove. Constants such as prove 
of type (o list) — * o are not formally allowed in our meta-logic (argument types are not 
permitted occurrences of the type o). To be formally correct here is simple: introduce a 
new primitive type, say 6, let prove be of type (6 list)— +o instead and replace occurrences 
of eval in N\ with a new constant, say evl, of type tm —t-tm — ► 6. For simplicity we 
continue to use just the type o. 

Lemma 7. For all closed atomic formula (eval {t,s} v), 

J\fo h (eval {t,s} v) if and only if M\ h prove (eval {£,s} v) ::nil. 

The proof uses a straightforward induction on the structure of proofs in the two systems. 

With SJ"i we have solved the problem of having inference rules with multiple premises. 
We are left to consider the problem of variables occurring in the premise but not in the 
conclusion of a rule. For the case of W*i this concerns rule A/"i.3. We can characterize 
this problem more generally, however, in the context of operational semantics. These dis- 
tinguished variables typically serve as placeholders or temporary names for intermediate 
results used in computing the final result of the computation specified by the inference 
rule. This idea is discussed in [How91] where a class of rules called evaluation rules is 
defined. Our concern here is in providing a technique for eliminating explicit reference 
to these variables. 

For the case of M\ we exploit properties particular to proofs in this system (and 
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subsequent ones as we introduce new proof systems). Unfortunately, these techniques 
do not extend to general, widely applicable strategies, but they do serve to illustrate the 
kind of reasoning possible for manipulating proof systems. In devising the steps involved 
in the following construction we were assisted by knowing the approximate structure of 
the resulting abstract machine. 

A useful manipulation of proof systems involves introducing partial instantiations of an 
inference rule. Partial instances of a rule are constructed by substituting (possibly open) 
terms for some of the schema variables of the rule, with the free variables of these terms 
becoming schema variables of the new rule. (A schema variable is one that is implicitly 
universally quantified.) Clearly we can always add (to a proof system) instances of a 
rule already in the system. Furthermore, we can replace a rule by a set of its partial 
instances if every instance of the original rule is also an instance of one of the partial 
instances. We apply this idea to rule Mi-2. The variable G in this rule is of type (o list) 
and because there are only two list constructors (nil and ::), all possible instances of G 
are also instances of either nil or A :: G' for some instances of A and G'. Thus, we can 
replace rule A/V2 by the two inference rules: 

Prove nil 

prove (eval {L,\M} {L, AM}) :: nil ^ X ' ° } 



prove A :: G' ^ 

prove (eval {L, AM} {L, AM}) :: A :: G' ' K 1 ] 

Notice that the premise of M±.2a is always trivially provable. In fact, we can unfold the 
rules A/'i-l and M\fla to produce the axiom 

(M x Za') 



prove (eval {L,AM} {L,\M}) :: nil 



Further, notice that rules Mi .26, 3, 4, 5 all have premises whose list arguments are non-nil 
and hence instances of A/'i-l cannot occur immediately above instances of these rules. 
If we use rule M\-2a' then we no longer need rule A/'i-l for non-trivial proofs. Taking 
rules A/"i-2a',26,3,4,5 (relabeling them as shown) yields the Mi proof system displayed 
in Figure 11. 

Lemma 8. For all s, t, Mi r- (prove (eval s t) ::nil) if and only if Mi h (prove (eval s t) :: 
nil). 

The proof of this Lemma is a straightforward induction on the size of Mi and A/2 proofs 
and uses the reasoning outlined above. 

Note that A/"i and AS are n °t precisely equivalent since Mi h (prove nil) but Mi \f 
(prove nil). Since we are only interested in atomic prove statements that contain a 
non-empty list of formulas, this discrepancy is irrelevant. 

The premise of rule A*2.3 contains two occurrences of each of the two variables V 
and M' which do not occur in the conclusion. The following proposition describes a 
redundancy within these proof rules that allows us to remove one occurrence of each of 
V and M'. 
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prove (eval {L,XM} {L,XM}) :: nil 

prove A::G 
prove (eval {I, AM} {L,XM}) :: A::G 

prove (eval {L,M} {X', AM'}) :: (eval {{L,N} :: L',M'} V)::G 
prove (eval {L, M ' N] V) :: G 

prove (eval X V):: G 
prove (eval {X :: L,0} V) :: G 

prove (eval {L,n} V) :: G 
prove (eval {X :: L, n + 1} V) :: G 

Fig. 11. The A/2 proof system 

Proposition 9. Let a be a formula, let 11 be an M2 proof of (prove a :: nil) and let 
(prove ai a n :: nil), for n > 2, be a formula occurring in II. Then for all i = 

1, . . . , n — 1, a,- has the form (eval s {£, Xt}) and a^ + i has the form (eval {s' ::£,t} v) for 
some terms s,s',t,t and v. 

Proof. Assume that the proposition does not hold for some formula a and proof II. 
Let prove a\ :: • • • :: a n :: nil be the formula in II closest to the root that does not have 
the desired form. Since n ^ 1, this atom is the premise of some inference rule. That 
inference rule must be A^2-3 since the conclusion of any other inference rule applied to 
that formula would not have the desired form. If the inference rule was A^-3, then the 
first two atoms, ai and 02, do have the required form. Hence, some pair in <i2 ::• • -::a„ ..nil 
must not have the required form, and again the conclusion of this inference rule does not 
have the require form, contradicting the assumption. □ 

Thus, every instance of the inference rule A/2-2 in an A^2 proof of (prove a :: nil) is 
also an instance of 

prove (eval {{L',M'} :: L,M} V) :: G 

prove (eval {L, AM} {L, AM}) :: (eval {{£', M'} :: L,M} V)::G ' 

This inference rule could therefore replace ^2-2. The structural information of Propo- 
sition 9 can be used in a more interesting fashion: we can introduce a new predicate 
symbol eval' : fotm — * fotm — > o and modify M2 to get the proof system so that 
atomic formulas of the form 

prove (eval ci {£1, Xt\}) :: (eval {C2 " {^2, ^2})" 

••• ::(eval {c„ ::4_i,f„_i} {£ n ,Xt n }) v.nil 

in Hi are replaced by formulas of the form 

prove (eval Ci {t\, Xt\}) :: (eval' c% {£2, ^2}) (eval' c n {£ n , Xt n }) :: nil 

in //s proofs. Here, a new predicate eval' is used to show that a variant of eval is 
intended: while the proposition (eval s t) states that s evaluates to t, the proposition 



(N2.I) 
(Af 2 .2) 



(A/" 2 .4) 
(A/" 2 .5) 
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prove (eval {I, AM} {L,XM}) ::nil 

prove (eval{{Li,Mi}::L,M} V) :: G 

prove (eval {L,XM} {L, AM}) :: (evaV {L x ,Mi} V) :: G 

prove {eval {L, M} {£', AM'}) :: (eval' {L,N} V)::G 
prove (eval {L,M'N} V) :: G 

prove (eval X V) ::G 



prove (eval {X :: L,0} V) :: G 
prove (eval {L,n} V) :: G 



prove (eval {X :: L,n + 1} V)::G 
Fig. 12. The JV3 proof system 



(M 3 .l) 
(M 3 .2) 
(M 3 .3) 
{Ms A) 
(Ms.5) 



(eval' s t) occurring in the context 

(eval s' {£, \t'}) :: (eval' si) nil 

states that {s :: £,t'} evaluates to t. The proof system M3 is displayed in Figure 12. 

Lemma 10. For all s,t, l~ (proue (eua/ s t)::nil) if and only if JV3 r- (prove (etia/ s t):: 
nil). 

The proof follows from Proposition 9 and the discussion above. Note that the distinc- 
tion between the predicate symbols eval and eval' is semantic. Syntactically, however, 
we can use just one symbol instead of the two if we restrict our attention to formulas of 
the form 

prove (eval c\ {£1, Aii}) :: (eval' {£ 2 , ^2}) (eval' c„ {£„, \t n }) - nil 

(for n > 1) because only the rules JV3.2 and ^3-3 manipulate eval' predicates and always 
as the second element in a list of formulas. 

The next transformation is a simple reorganization of data structures that exploits 
the isomorphism between a list-of-pairs and a pair-of-lists. The constants eval and eval' 
can be viewed as pairing constructor (pairing a term with a value). The predicate 
prove takes a list of such pairs. An equivalent formulation uses the binary predicate 
provei : (fotm list) — ► (fotm list) —>■ o that takes a pair of lists. The explicit pairing 
constructors can be eliminated in this way. This is done in the proof system M\ displayed 
in Figure 13. 

Note that for any formula occurring in an Ma proof we can easily construct the corre- 
sponding formula occurrence in an proof: use eval to pair together the first elements 
in the lists, and use eval' to pair together all the remaining elements. Given the motiva- 
tion for Ma above and the fact that the syntactic distinction between the constructors 
eval and eval 1 is not relevant, the following is immediate. 

Lemma 11. For all s,t, M3 h (prove (eval s t) :: nil) if and only if Ma h (provei s :: 
nil t :: nil). 

Recall that an AES-defining system must have an output variable as part of the atomic 



From Operational Semantics to Abstract Machines 



25 



provei {L,XM} :: nil {L,XM} :: nil 

prove! {{Li,Mi}::L,M} ::S V ::T 
prove-, {L,\M}::{L!,M!}::S {L,XM}::V ::T 

provet {L,M}::{L,N}::S {£', AM'}:: V :: T 
prova {L,M'N}::S V :: T 

prove! X :: S V ::T 



prove! {X::L,0}::S V ::T 
prove! {L,n}::S V :: T 



prova {X :: L,n+\}::S V ::T 
Fig. 13. The Mi proof system 



proves {L, XM} :: nil {L, AM} :: nil {£,AM} 

prove 2 {{Li,Mi} ::X,M} :: S V :: T Z 
prove 2 {I,AM}::{ii,Mi}::5 {Z, AM}:: V ::T Z 

prove 2 {L,M}::{L,N}::S {V ,XM'}::V ::T Z 
prove 2 {L,M'N}::S V ::T Z 

prove? X :: S V ::T Z 
prove 2 {X :: L,0} :: S V :: T Z 

prove 2 {L,n}::S V ::T Z 



(M<.1) 

(M,.2) 
(A/V3) 

(M*A) 

(// 4 .5) 

(Af s .l) 
(AT..2) 
(Af 6 .3) 
(7V S .4) 
(Af 5 .5) 



prove 2 {X :: £,n + 1} :: 5 V :: T 2 
Fig. 14. The Mb proof system 

formula being proved. This variable is set by the axioms and is preserved by all the other 
inference rules. Towards such a structure for our rules, we state the following trivial 
proposition. 

Proposition 12. For any terms s,t, the leaf of an Ma proof of (provei s :: nil t :: nil) 
must be an occurrence of the formula (provei t :: nil t :: nil). 

We exploit this property of proofs by introducing a third argument to the provei 
predicate, modifying the one Ma axiom to identify this new argument with the final 
value t from the second argument t :: nil and modifying the remaining inference rules to 
preserve the value of this argument. The resulting proof system, called M5 and displayed 
in Figure 14, replaces provei with the new predicate proves : (fotm list)— >■( fotm list)—* 
fotm — »• o of three arguments. 

Lemma 13. For all s,t, Ma h {provei s :: nil t :: nil) if and only if M5 h (prove2 s :: 
nil t :: nil t). 

The proof follows from Proposition 12. 



J. Hannan and D. Miller 



26 



proves {L, XM} :: nil {L,XM} 

proves {{L',N} ::L,M} .:S Z 
proves {I, AM} :: {L',N} :: S Z 

proves {L,M} ::{L,N}::S Z 
proves {L,M " N} ::S Z 

proves X :: S Z 
proves {X ::L,0} ::S Z 

proves {L, n} :: S Z 
proves {X :: L, n + 1} :: 5 Z 

Fig. 15. The A/^ proof system 

Now, Af 5 is not an AES-defining system only because in rule Ms .3 the variables L' and 
M' occur in the premise but not in the conclusion. Consider simplifying the inference 
rules of Af$ by replacing each inference rule of the form 

(prove? t[ t'? t' 3 ) w . th (prove 3 t[ t' 3 ) 
(prove 2 h t 2 ^3) (prove 3 t 1 t 3 ) 

where proves : (fotm list) — ► fotm — ► o is a new binary predicate. This kind of gener- 
alization is complementary to the instantiation transformations that we applied earlier. 
The resulting system, called is displayed in Figure 15. 

Observe that all schema variables free in the premise of any A*6 rule are also free in 
the conclusion of that rule. Furthermore, observe that for every inference rule, the 
schema variables occurring free in the second argument of prove? occur nowhere else 
in the premise. Thus this second argument is, in some sense, independent of the other 
arguments in premise formulas. Observe also that in any .A/Vprovable formula the first 
and second arguments are always lists of the same length and the second argument is 
always of the form Xsi} :: {£?, As 2 } nil. Thus for any .A/Vprovable formula, if 

the first and third arguments of this formula match the corresponding arguments in the 
premise of an inference rule, then the second argument must also match its corresponding 
argument in the premise of the rule. That is, the second argument supplies no constraint 
on the construction of N$ proofs and so can be safely discarded. This fact is formalized 
in the proof of the following proposition. 

Lemma 14. For all s, t, N5 r- (prove? s ::nil t ::nil t) if and only ifA^ H (prove 3 sv.nili). 

Proof. The proof in the forward direction is immediate: given a proof in J\f$ simply 
delete the second argument of all atomic formulas and change prove? to proves through- 
out. We prove the reverse direction by proving the slightly more general statement: for 
all n > 0, and terms s,si, . . . ,s n ,t, if N§ h (proves s„ sj :: s :: nil t) then there 

exists terms t\, . . . ,t n such that M5 V- (prove? s n ::...::si::s::nil t n ::- -::ti::t ::nil t). 
The proof proceeds by induction on the height h of an J^e proof II. 



(Af 6 .l) 

(^6-2) 
(JV6.3) 

(Ms. 4) 
(A/e.5) 
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{proves {£, \s}::nil {£, As}) 
and so n = 0. The corresponding A/"s proof is simply 



(prove^ {£,Xs} :: nil {£, Xs} :: nil {£,Xs}) 

Step: Assume the statement holds for proofs of height h > 1 and let II be an N§ 
proof of (proves s n :: . . . :: s\ :: s :: nil t) with height h+l. We show that there exists 
an jV"5 proof A of (prove-i s n :: . . . :: «i :: s :: nil I t) for some t = t n :: • • • :: <i :: t :: ni/. 

Let (proves s' m s\ :: s' :: nil t) be the premise of the last inference of II. By the 

inductive hypothesis, there exist terms t\, . . . ,t m such that (prove-i s' m :: . . . :: :: s' :: 
nil t m :: ■ ■ ■ :: ti :: t :: nil t) has an A/5 proof A'. We proceed now by cases according to 
the last inference rule of II. 

1 If the last rule is ^6-4 (A/V5) then n = m, and let £ = t m :: • • • :: f i :: t :: nil. The 
required proof A is then built from A' and Af$ A (jV's .5) . 

2 If the last rule is Af&.2 then n = m + 1 and sj„ = {{^i,nii} "€2,0*2} for some 
£i,mi,£2, «2- Let € = {^2,^1712} :: t m ■ ■ t\ :: t :: nil . Again the required proof A 
is constructed from A' and M5.2. 

3 If the last rule is Afe.S then m = n + 1 and m > 0. Let £ = J m _i ti ::t:: nil. 
The proof A is constructed from A' and A^5.3. 

It is trivial to verify that in each case the £ we construct is of the form ::ti ::t::nil 

for some t 1} . . . ,t n . Letting n = 0 yields the required proof for the lemma. □ 

We now can state the main result of this section. 

Theorem 15. For all s, t, Afo h (eval s t) if and only if Af$ h (proves s nil t). 

The proof follows from linking together all the lemmas in this section. 

Notice that is simply an AES-defining proof system for call-by-name evaluation if 
we add to it the load rule 

proves {nil , M} :: nil Z 
~ cbn M Z ~ ' 

The abstract machine encoded by this proof system is given in Figure 16. Its state 
consists of a list (or stack) of closures {E, M] :: S. Compare this with the description in 
Figure 2 in which the state consists of the triple (E, M, S). 

5.2. Constructing a Call-by-Value Machine 

In this section we construct a machine for call-by- value evaluation using a strategy similar 
to the one applied in the previous section. Starting with the first-order specification Vo 
derived in Section 4.3, we construct the proof system Vi (displayed in Figure 17) in which 
inference rules involving atomic formulas are replaced by inference rules involving stacks 
of such formulas. 
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M 




{nil, M] :: nil 


{E,M~ N} 


::S 




{E,M}::{E,N}::S 


{E,XM}::{E',N} 


::S 


=> 


{{E',N}::E,M}::S 


{X::E,0} 


::S 


=> 


X ::S 


{X::E,n + l} 


::S 


=> 


{E,n} :: S 


{E,\M} :: 


nil 




{E, AM} 



Fig. 16. A call-by-name abstract machine 



prove nil 
prove G 

prove (eval {E, AM} {E,\M})::G 

prove (eval {E, M) {£", AM'}) ::(eval {E,N} R) 

::(eval {R::E',M'} V) :: G 

prove (eval {E, M " N} V) :: G 

prove G 
prove (eval {X :: £, 0} X)::G 

prove (eval {E,n} V)::G 
prove (eval {X :: E,n + 1} V) :: G 

Fig. 17. The Vi proof system 

Lemma 16. For all terms £, s and v, 

Vo h (eval {£,s} v) if and only if Vi h (prove (eval {£,s} v) :: m7). 

The proof is similar to the proof of Lemma 7. 

As with the call-by-name case we are again faced with the task of eliminating variables 
that occur only in the premise of a rule. The problematic variable occurrences in this case 
are E' and M' in rule Vi.3. There seems to be no simple generalization to Proposition 9 
that reveals any redundancy in the inference rules of V\. Thus, we appeal to a more 
general transformation (described in more detail in [Han90]) for introducing value stacks. 
We give here just an outline of this transformation and its applicability to operational 
semantics. 

The formula (eval p v) represents a relation between an input program p and an output 
value v. We can formalize this notion of input and output by considering the following 
general form of an inference rule. 



(Vi.l) 
(Vi-2) 

(Vi.3) 

(Vj.4) 
(Vi.5) 



prove (eval p\ v±) :: (eval p2 V2) ::•••:: (eval p n v n ) :: G 



prove (eval p v) ::G 



(*) 
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The use of explicit lists of formulas enforces a left-to-right order in which these formulas 
are solved during bottom-up proof construction. Assume that during proof construction 
p is a closed term (known) and v is a variable (unknown) yet to be instantiated with a 
closed term. To ensure that a program pi depends only on known information we restrict 
occurrences of free variables as follows: every free variable of pi must either occur in 
p or in some Vj for some j < i. Thus an instance of program pi can be determined 
from the program p (which we assume is given as input) and the results vj of previous 
computations. We also assume that every variable occurring in v occurs in some v,- 
(1 < t < n). For a similar characterization of input and output within evaluation rules, 
see [How91]. 

If such variable restrictions hold for all inference rules in a proof system then we 
can reformulate the inference rules into a more functional, rather than relational, style. 
Instead of a binary predicate eval : fotm — ► fotm — >• o taking a program and a value 
as arguments we use a unary predicate eval\ : fotm — ► instr taking just a program 
as an argument and producing an instruction (using the new type instr). The unary 
predicate prove : (o list) — ► o is replaced by a ternary predicate provei : (instr list) —* 
(fotm list) — + fotm — s- o. The first argument is a list of instructions, replacing the list of 
predicates. The second argument is a value stack representing the values produced by 
instructions that have already been evaluated. The third argument represents the result 
of the original program (occurring at the root of the proof tree). Now the basic idea of 
the transformation we employ is that the value or result of a program is pushed onto the 
value stack during bottom-up proof construction. So if (prove (eval pv) :: nil) is provable 
then a proof of (provei (evali p) ::£ s vo) must have a subproof (provei £ v.: s vo). 
This transformation directly addresses the elimination of meta-level variables occurring 
in the premise, but not conclusion, of inference rules. These variables provide access to 
intermediate results, and this is the same service the stack provides. The full details of 
this transformation are presented in [Han90]. 

Using this transformation we can construct the new proof system V2 (given in Fig- 
ure 18) from W This step introduces a new constant <j> : instr. 

Lemma 17. For all terms p and v, V\ h (prove (eval p v) :: nil) if and only if V2 H 
(provei (evali p) :: nil nil v). 

The proof follows immediately from Theorem 7.11 of [Han90]. 

In any Improvable proposition (provei ^ s z ), the list £ consists only of evali or <t> 
instructions. As evali an d <j> are the only constructors for instr, we can replace the 
terms of type instr with ones of type fotm. We first replace provei with a new predicate 
proves : (fotm list) —* (fotm list) — ► fotm — ► o; then replace terms (evali p) with just 
p; and replace <f> : instr with a new constant xj> : fotm. Performing this transformation 
yields V3, displayed in Figure 19. 

Lemma 18. For all terms p and v, V2 H (provei (evali p) nil nil v) if and only if 
V3 h (prove2 p :: nil nil v). 

The proof is a trivial induction on the height of proof trees. 

For any V3-provable proposition (prove2 £ s v), I is a list in which each element is 
either a closure {e,t} or the term ij>. We can view this as a list of only closures if 
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provei nil V :: nil V 

provei C {E,XM} :: S V 
prove! (evah {E,XM})::C S V 

prove! (evah {E, M}) :: (evah {E, N}) :: <f> :: C S V 
provei (evah {E,M ~ N}) :: C S V 

provei C X ::S V 

provei (evah {X :: E, 0}) :: C S V 

provg (evah {E,n}) ::C S V 
provei (evah {X :: E, n + 1}) :: C S V 

provei (evah {R :: E, M}) :: C S V 
provei <!>::C R :: {E, AM} :: S V 

Fig. 18. The V2 proof system 



prove2 nil V :: nil V 

prove 2 C {E,\M} :: S V 
proves {E,XM} ::C SV 

prove 2 {E, M} :: {E, N} :: j) :: C S V 
prove 2 [E,M- N}::C S V 

prove 2 C Xr.SV 
prove 2 {X :: E,0} ::C S V 

prove 2 {E,n}::C S V 
prove 2 {X E,n + 1} ::C S V 

prove 2 {R:: E,M} ::C S V 
prove 2 ijjy.CR :: {E, AM} :: S V 

Fig. 19. The V3 proof system 

we introduce a new symbol ip' : fotm and replace ip with a dummy closure {nil,tp'}. 
We can again replace such a list with a pair of lists by introducing a new predicate 
prove 3 : ((fotm list) list)^(fotm list)— > (fotm list)-^fotm-^o. Now instead of having a 
list of pairs (the first argument of prove 2 ), we have a pair of lists (the first two arguments 
of prove 3 ). We are thus led to the proof system V 4 displayed in Figure 20. 

Lemma 19. V 3 h (prove 2 {£,m}::nil nil v) if and only if V4 h (prove 3 £::nil m:: 
nil nil v) . 

The proof is a trivial induction on the height of proof trees. 

The dummy environment associated with the constant ip' can be eliminated since it 
contains no information and it only appears on top of the environment stack E when 



(V2.I) 
(V 2 .2) 



(V 2 .4) 
(V 2 .5) 
(V 2 .6) 

(V3.I) 
(V 3 .2) 
(V3.3) 
(V 3 .4) 
(V3.5) 
(V3.6) 
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•proves nil nil V :: nil V 

proves L C {E,XM}::S V 
proves E ::L XM :: C S V 

proves E :: E :: nil :: L M :: N :: ij>' :: C S V 
proves E::L {M'N)::C S V 

proves L C X :: S V 
proves (X :: E) :: L 0 :: C S V 

proves E :: L n :: C S V 
proves (X :: E) :: L n + 1 :: C S V 

proves (R::E)::L M::C S V 
proves nil v.L f :: C R :: {E, AM} :: S V 

Fig. 20. The V4 proof system 



(V4.1) 
(V4.2) 
(V4.3) 
(V4.4) 
(V4.5) 
(V4.6) 



is on top of the term stack C. Rules V4.3 and V4.6 can be replaced by the following two 
rules. 

prove 3 Ev.Ev.L M :: N :: ip' :: C S V 

prove 3 E::LM'N::CSV C 4- J 

proves (R::E)::L M :: C S V 
proves L tp' ::C R :: {E,XM} :: S V 1 4 ' 

If we combine the first three arguments of proves into a tuple (making proves a binary 
predicate) then the resulting proof system is AES-defining. Figure 21 contains the cor- 
responding abstract evaluation system: the CLS machine. (We have switched the order 
of the first two arguments.) It can be viewed as a dumpless SECD machine. As in the 
previous section we can introduce an appropriate rule to load the machine. This can be 
derived by considering how the original binary predicate (eval P V) has evolved into the 
four-place predicate {proves L C S V). The first argument of proves, a stack of envi- 
ronments, corresponds to the environment (E) and dump (£)) of the SECD. The second 
argument of proves corresponds to the code stack (C) of the SECD. The third argument 
of proves acts as the argument stack (5) of the SECD. The constant rp' in our machine 
corresponds to the instruction ap (or @) found in the description of the SECD machine 
[Lan64] . This simplified machine avoids using an explicit dump in favor of maintaining a 
stack of environments such that the i th term on the code stack is evaluated with respect 
to the i th environment on the E stack (ignoring the occurrences of rp' which are not 
evaluated with respect to an environment). While the original SECD machine stores 
the entire state on the dump, the only required information is the old environment and 
the code associated with it. Comparing this machine with the SECD machine given in 
Figure 2, we note a one-to-one correspondence between the rules in the two machines, 
except for the two rules that manipulate the dump of the SECD. 
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::C, 
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{nil, nil, V :: S) 




V 







Fig. 21. The CLS machine 

There is a close relationship between our CLS machine and the Categorical Abstract 
Machine (CAM) [CCM87]. The latter can be viewed as a compiled version of the former. 
Both utilize a stack of environments and a stack of result values, though in the CAM 
these two stacks have been merged into one structure. The codes for the two machines 
are different. The CLS machine operates on a list of A-terms (plus the constant ip') while 
the CAM operates on a list of instructions for manipulating its stack. These instructions 
do, however, correspond closely to operations performed on terms in the CLS, and recent 
work has shown this correspondence by defining the compilation of A-terms into CAM 
instructions from the definition of the CLS machine [Han91]. 

6. Language and Machine Extensions 

In this section we consider some extensions to our simple, object-level programming 
language, making it more realistic. We demonstrate how these new features can be 
specified via our high-level inference rules, and we outline how the transformations of 
the previous section apply to these new features. 

6.1. The Second-Order Lambda Calculus 

The object-language we have considered so far is just the untyped A-calculus. Considering 
the simply typed calculus as the object-language adds nothing new to the theory of 
evaluation, since evaluation, in this case, can be viewed as an untyped operation. We 
can just erase the types of a simply typed term and apply untyped reduction to these 
terms. 

A more interesting case involves the second-order lambda calculus, or System F [Gir86], 
in which types play a more important role during reduction. We begin by defining the 
syntax for this calculus. 

The types of F are given by the following grammar, where a ranges over type variables. 

T ::= a \ T^T \ Va.T. 
The terms of F are defined inductively as follows: 
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1 for any type a, we have a denumerable set of variables of type <r, and these are all 
terms of type <r; 

2 if t is a term of type r and x" is a variable of type a, then Xx" .t is a term of type 

r; 

3 if t and u are terms of types a — > r and ct, respectively, then (f w) is a term of type 
r\ 

4 if t is a term of type <r and a is a type variable, such that for all free variables x T 
in t, a does not occur free in t, then Aa.t is a term of type Va.cr; and 

5 if t is a term of type Aa.a and r is a type, then f{r} is a term of type a[r/a]. 

Reduction in System F can be characterized by two rules: 

(Xx a .t)u => t[u/x a ] and (Aa.t){r) =^ t[r/a], 

with the first just being the typed version of /?-reduction for term application. Our goal 
is to axiomatize normal-order reduction (to weak head normal form) as we did with the 
untyped calculus. We start by defining an abstract syntax for types and terms of System 
F. We assume two (meta-level) syntactic sorts, ty and tm, to denote object-level types 
and terms, respectively, of System F. The following signature will be used to present the 
abstract syntax of such terms and types. 

=$■: ty ^ty —>ty app : tm — ► tm — ► tm 

pi : (ty — ► ty) — > ty abs : ty — ► (tm — + tm) — » tm 

tapp : tm —>ty—> tm 

tabs : (ty — > tm) — ► f m. 

Types are constructed using the two constants =>• (infix) and pi, for example, (pi Xa(a =>■ 
a)). Terms are constructed using the remaining constants. Term application is denoted 
as app; term abstraction is denoted as abs, where its first argument is the type of the 
abstracted variable. Type application is denoted by tapp and type abstraction is denoted 
by tabs. For example, we can represent the term Af3((Aa(Ax a .x)){/3 — * /?}) by the term 

(tabs Xb(tapp (tabs Xa(abs a Xx.x)) (b 6))). 

As we did in Section 4, we can axiomatize a reduction relation by introducing a pred- 
icate symbol eval : tm —>tm-^o. The four rules in Figure 22 axiomatize normal-order 
reduction to weak head normal form. Notice how meta-level /^-reduction provides object- 
level substitution of both terms and types. 

Applying techniques analogous to those of Section 4, we can introduce a first-order 
syntax for this calculus, using de Bruijn-style notation. This syntax is given by the 
following signature 

=>: foty —*■ foty — ► foty ' : (fotm x fotm) —> fotm (infix) 

V : foty —y foty X : (foty x fotm) —*■ fotm 

tvar : not —* foty : (fotm x foty) —* fotm (infix) 

A : fotm — ► fotm 

var : not fotm 

(The overloading of the type for =i> should not cause any confusion). Type application 
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eval (abs T M) (abs T M) eval (tabs H) (tabs H) 

eval P (abs T M) eval (M Q) V 

eval (app P Q) V 

eval P (tabs H) eval (H T) V 

eval (tapp P T) V 

Fig. 22. Call-by-name evaluation for System F 



eval {E,X(T,M)} {E,X(T,M)} eval {E,AH} {E, AH} 

eval {E,P} {E',\(T,M)} eval {{E,Q} :: E',M} V 

eval {E,P'Q} V 

eval {E,P} {E',AH} eval {{\E,T\} :: E',H} V 

eval {E,P"T} V 

eval X V eval {E, n} V 

eval {X::E,0} V eval {X::E,n+l} V 

Fig. 23. A first-order specification of call-by-name evaluation for System F 

is written t " r for term t and type r. Type abstraction is written Af for term t. The 
non-negative integers are de Bruijn indices and are coerced into types foty and fotm 
by tvar and var, respectively. For brevity, we simply write n for both (tvar n) and 
(liar n). Here, A, A, and V act as nameless binders and an occurrence of a (type or term) 
variable is given by an index that refers to the number of A's, A's, and V's to its (the 
variable's) binding occurrence. For example, the term Aa.Xx a .x becomes AA(1, 0). The 
1 refers to the type variable bound by A and the 0 refers to the term variable bound 
by A. The abstract syntax of the term Af3((Aa(\x a .x)){0 — > /?}) over this signature is 
A((A(A(1,0))"(0 =►<))). 

Translating the evaluation specification above into one using this new syntax, following 
the approach of Section 4, yields the proof system in Figure 23. We have introduced a 
new form of closure, {|£',T|}, denoting the closure of type T with environment E, as 
types may now contain variables that are bound in the environment, just as with terms. 

Finally, by following the steps of Section 5.1, we can produce an abstract machine 
corresponding to these rules and it is given in Figure 24. 

Evaluation here is not sufficiently different than in the untyped case, since types are 
never evaluated and once they are moved into a closure, they are never retrieved. This ex- 
ample is included here largely to show that the transformation techniques of the previous 
two sections can be applied equally well in this typed situation. 
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{E, AM} :: 


nil 
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{E,AM} :: 


nil 




{E,AM} 





Fig. 24. A machine for System F 
6.2. Recursive Expressions 

Recursion can be introduced into our object-language by introducing a constant that 
acts like the Y combinator. In particular, let the constant fix : (tm — *• tm) — ► tm be 
added to the second-order signature used in the beginning of Section 4. Evaluation of 
recursive expressions is given simply by the rule 

eval (M (fix M)) V 
eval (fix M) V 

Operationally, this rule performs an unwinding of the recursive definition by using meta- 
level /3-reduction to do substitution. Those transformations used in Section 4 that 
replaced a second-order signature with a first-order signature can be applied also to 
this rule. The second-order constant fix must be replaced with a first-order constant 
H : fotm^fotm that acts as a binder just like the constant A. The corresponding trans- 
formation of the above evaluation rule, which can be added to both the call-by-name 
proof system Mo and the call-by- value proof system Vo, is the following rule. 

eval {{E,nM} ::E,M} V 
eval {E,fiM} V 

Notice that this rule does not violate any of the conditions for AES-defining proof sys- 
tems. The sequence of transformations applied to proof systems in Section 5 can be 
applied to both the proof systems Mo and Vo extended with this rule for recursion. In 
the call- by-name case, we would need to simply add the rewrite rule 

({E,liM}::S) ^ {{{E t fiM} :: E, M} :: S) 

to the machine in Figure 16. 

If we perform the series of transformations used for call-by-value evaluation, we need 
to add to proof system V4 the inference rule 

proves ({E,nM}::E)::L M::C S Z 
prove z E :: L nM :: C S Z 
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which translates to the rewrite rule 

(fiM :: C, E :: L, S) (M :: C, ({E,(mM} :: E) :: L, S). 

This rewrite rule can be added to the specification of the CLS machine in Figure 21. 

6.3. Conditional Expressions 

Introducing a conditional expression to our object-language provides a challenge requiring 
a new transformation. Using the constants if : tm — > tm — ► tm —* tm, true : tm, and 
/a/se : tm we can construct terms representing conditional expressions. Evaluation of 
such expressions is specified via the two inference rules 

eval P true eval Q V eval P false eval R V 

eval (if P Q R)V an eval (if P Q R) V ' 

The transformations to abstract syntax that uses a first-order signature are straightfor- 
ward and yield the two rules 

eval {E,P} true eval {E,Q} V 
eval {E, (if P Q R)} V 

eval {E,P} false eval {E,R} V 

eval {E, (if P Q R)} V 

(Here, we assume that the types of if, true, and false now involve the primitive type fotm 
instead of tm.) Let V' 0 be Vo extended with these two new rules (we only consider the 
more difficult call-by- value situation here). Transforming Vo into Vi required introducing 
the prove predicate and an explicit list of formulas. Following this transformation here 
yields V\ , which is just Vi extended with the rules 

prove (eval {E,P} true) :: (eval {E,Q} V) :: G 
prove (eval {E, (if P Q R)} V) :: G 

prove (eval {E,P} false) ■.-.(eval {E,R} V)::G 
prove (eval {E, (if P Q R)} V) :: G 

Paralleling the transformation from V\ to V2 yields V' 2 , which is V2 plus the following 
four rules: 

provet (evah {E , P}) :: {fa E Q) ::C S Z 
prove! (evah {E, (if P Q R)}) ::C S Z 

prove! (evah {E , P}) :: (<f> 2 E R) :: C S Z 
prove! (evah {E, (if P Q R)}) ::C S Z 

prove! (evah {E,Q}) ::C S Z prove! (evah {E,R}) ::C S Z 

prove! (<t>i E Q)::C true :: S Z prove! (h E R) ::C false :: S Z 

Notice that the evaluation of a conditional uses the same stack that is used for functional 
application. The final two transformations of V2 to V4 were simplifications of data 
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structures, and these two transformations apply directly to the rules above, yielding the 
following four rules that must be added to V4 to derive V 4 : 

proves E::E::L P :: (fa Q) :: C S Z 
prove 3 E ::L (if P Q R) ;.C S Z 

proves E::E::L P :: (fa R) :: C S Z 
proves E::L (ifPQR)::C S Z 

prove 3 E::L Q ::C S Z prove 3 E :: L R::C S Z 

prove 3 E::L (fa- Q) :: C true :: S Z prove 3 E :: L (fa R) :: C false :: S Z 

Notice that (fa E Q) and (fa E R) have been replaced by just (fa Q) and (fa R) m 
this transformation since the environment E appears at the front of the list in the first 
argument of prove2 in those inference rules that "introduce" fa and fa. 

The proof system V 4 is an AES-defining proof system, and the abstract machine it 
encodes is formed by adding the following rewrite rules to those in Figure 21. 

{E::L, (if P Q R) ::C, S) => (E :: E :: L, P :: (V-i Q) :: C , S) 

(E :: L, (ifPQR) ::C, S) => (E :: E :: L, P :: (V> 2 R) :: C, S) 

(E::L, (fa Q) :: C, true :: S) => ( E :: L, Q::C, S) 

{E::L, (fa R) :: C , falsev.S) => ( E :: L, R r.C, S) 

This abstract machine is not as simple as we would like it to be because the first two 
rewrites share the same left-hand side. This means that rewriting would need to perform 
backtracking in order to do evaluation. Appendix B contains a transformation that can be 
used to "factor" the common parts of these two evaluation rules. Applying this factoring 
transformation to the four inference rules that are added to V4 yields the following three 
rules: 

prove 3 E::E::L P :: (choice (fa Q) :: nil (fa R) ■■ nil) ::C S Z 
prove 3 E :: L (if P Q R) :: C S Z 

prove 3 L d@C S Z prove 3 L C 2 @C S Z 

proves L (choice Cy C2) ::CSZ prove 3 L (choice C\ C2) -' C S Z 

Here, the infix symbol @ is used to denote list concatenation. 

Because the only rule that mentions choice in the premise is the first rule above, 
the last two rules can be replaced by the following instantiations (making the obvious 
simplification of (a :: nil) @ C to a :: C): 

prove 3 L (fa Q) ::C S Z 
proves L (choice (fa Q) :: nil (fa R) :: nil) :: C S Z 

prove 3 L (fa R) ::C S Z 

prove 3 L (choice (fa Q) :: nil (fa R) nil) ::C S Z 

We can now unfold these two rules with the two containing ^1 and fa in their conclusions. 
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This yields the following two rules: 

prove 3 E::L Q ::C S Z 

■proves E :: L (choice (fa Q) :: nil (fa R) nil) :: C true :: S Z 

proves E :: L R::C S Z 
proves E :: L (choice (fa Q) nil (fa R) nil) :: C false :: S Z 

These two rules plus the if introduction rule above provide a suitable definition for the 
conditional expression. The resulting proof system is AES-defining and rewriting will 
not require any backtracking. The corresponding abstract machine is given by adding 
the following rewrites: 

(E :: L, (if P Q R) :: C, S) => 

(E :: E :: L, P :: (choice Q) :: nil (ip 2 R) :: nil) :: C, S) 

{E::L, (choice (fa Q) :: nil (fa R) :: nil) :: C , true :: S) => (E::L, Q ::C, S) 
(E ::L, (choice (fa Q) :: nil (fa R) :: nil) :: C, false ::S) => (E::L, R ::C, S) 

We can simplify these rules by combining some constants: since choice expressions are 
always of the form (choice (fa Q) y.nil (fa R) ::nil), we can introduce the "abbreviated" 
form (choice' Q R), modifying the rules appropriately. 

6.4- Pairs 

We can introduce strict pairs to our object-language by introducing a new signature item 
pair : tm —* tm — ► tm for constructing pairs of terms. In the highest level evaluator, the 
inference rule for evaluating a pair is 

eval Pi Vi eval Pi V2 

eval (pair Pi P2) (pair V\ V2) 

In the first-order setting using closures, the rule for evaluating a pair is 

eval {E,Pi} Vi eval {E,P 2 } V 2 

eval {E, (pair Pi P 2 )} (pair Vi V 2 ) 

and this can be added to Vo- (Again, we assume that the type of pair is now fotm—* 
fotm —* fotm.) 

Now, following the derivations in Section 5.2, we eliminate branching rules, producing 
the rule 

prove (eval {E,Pi} Vi)::(eval {E,P 2 } V 2 ) :: G 
prove (eval {E,(pair P x P 2 )} (pair Vi V 2 ))::G 

To accommodate the next step, that of introducing an value stack, we first split the 
above rule into the following two rules: 

prove (eval {E, Pi} Vi) :: (eval {E,P 2 } V 2 ) :: (mkpair Vi V 2 V) :: G 
prove (eval {E,(pair Pi P 2 )} V) :: G 
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prove G 

prove (mkpair V\ V 2 (pair Vi V 2 )) :: G 

These two rules essentially split the act of producing the values V\ and V 2 from the act 
of constructing the pair of these two values. Using these two rules we can introduce a 
value stack, producing the following new rules: 

provei (evah {E, Pi}) :: (evah {E, P 2 }) :: <j> 3 " C S Z 
provei (evali {E , (pair Pi P2)} ) :: C S Z 

provei (mkpair V\ V2) "CSZ 
provei <t>3 C V 2 :: V X ::S Z 

provei C (pair V x Vi) :: S Z 
provei (mkpair Vi V 2 ) " C S Z 

Folding the latter two rules yields 

provei C (pair V\ Vi) :: S Z 
provei <f>z :: C V2 :: Vi :: S Z 

The remaining transformation steps are straightforward, producing the following rules 
for the CLS machine: 

((pair Pi P 2 ) :: C, E :: L, 5) (Pi :: P 2 :: ^3 " C, E :: E :: L, S) 

(rP 3 ::C, L, V 2 :: V x :: S) (C, L, (pair Vi V 2 ) :: 5). 

(The switch from $3 : o to ^3 : fotm reflects the change in type of the instruction list C.) 
6.5. Primitive Constants and Constructors 

We can introduce constants and data constructors in a variety of ways. We present a 
method in which they are treated similarly. All constants are assumed to be in normal 
form, and so they evaluate to themselves. Data constructors are assumed strict and their 
arguments are encoded as pairs. 

For constants, we introduce the new signature item const : string — + fotm, and we 
represent each constant c of our object-language by the term (const c). Then we specify 
evaluation by the single rule 

eval (const c) (const c) 

and this translates to the machine rule 

((const c) :: C, E :: L, S) => (C, L, (const c) :: S). 

For data constructors, we introduce the new signature item constr, and we represent 

each constructor c(tl tn) of our object-language by the term (constr c args) in which 

args is the encoding of the tuple (ti, . . . ,t n ). Then we specify evaluation by the single 
rule 

eval A B 
eval (constr K A) (constr K B) 
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and this translates (via a process similar to that for pairs) to the machine rules 

((constr K A) :: C, E :: L, S) (.4 :: (mkconstr K) :: C, L, S) 

{(mkconstr K) :: C, E :: L, B :: S) (C, L, (constr K B) :: S). 

6.6. Primitive Functions 

Primitive functions can also be added in a straightforward way. We first assume that 
all primitive functions are strict and unary. In our first-order abstract syntax we encode 
primitive operators by introducing the constructor prim : string — > fotm in which the 
operation is denoted by a string name. The evaluation of primitive functions can be 
specified via the rule 

eval {L,M} (prim Op) eval {L,N} R oper(Op,Q) — V 

eval {L, M ' N} V ' 

where oper(Op, Q) = V denotes the property that applying the primitive function Op to 
the argument Q yields result V. 

Now, following the derivation of Section 5.2, we can produce the following two rules: 

((M * N) :: C, E :: L, S) (M :: N :: V>4 " C, E :: E :: L, S) 

(i> 4 :: C, L, R :: (prim Op) :: S) => (C, L, oper(Op, R) :: S). 

Adding these two rules to our CLS machine produces a problem similar to the one 
encountered with the conditional statement. The machine has two possible reduction 
steps for applications: one for the case of primitive function application (introducing the 
constant ^4) a nd one for application of a lambda abstraction (introducing the constant 
V>')- By factoring these two rules using the transformation described in Appendix B, 
performing some unfolding and renaming some collection of constants, we can simplify 
the description of application to the rules below (for a new constant ip5 '■ fotm). 

((M ' N) :: C, E :: L, S) =» (M :: N :: Vs " C, E :: E :: L, S) 

(4> 5 ::C, L, R ::{E',M} ::S) => (M :: C, (R :: £") :: L, S) 
<Vs C, L, R :: (prim Op) :: S) => (C, L, oper(Op, R) :: S). 

7. Related Work 

Previous work using abstract machines as an intermediate-level representation for a lan- 
guage has relied on informal methods for defining the machines or for relating them to 
source languages, or both. The principal advantage of this approach is the flexibility af- 
forded in designing the structure of machines, as there are no a priori restrictions on the 
data structures or control structures that can be used. Considerations of efficiency, not 
evident in the semantic specifications, can be accommodated. The principal disadvan- 
tage, however, is the potential difficulty of proving that the abstract machines correctly 
implement a given language. Another disadvantage is the potential difficulty in extending 
the machines to accommodate new language features. 

The prototypical abstract machine for a functional programming language is the SECD 
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machine, and a proof of its correctness can be found in [Plo76]. While demonstrating the 
correctness of this machine with respect to an operational semantics, this proof does not 
provide much intuition regarding the overall structure of the machine or how it can be 
extended to handle a more substantial language. Our methods, however, provide a basis 
for proving such machines correct and, as demonstrated in Section 6, provide support 
for extending the machines to accommodate additional language features. 

An example of an abstract machine used in an actual implementation of a language is 
the Functional Abstract Machine [Car84], a variant of the SECD machine, which has been 
optimized to allow fast function application. This machine, designed for implementing the 
ML language, addresses issues including efficient local variable storage, efficient closure 
construction and function manipulation, and exception handling. The design of this 
machine was influenced both by the structure of ML, for which it provides an intermediate 
level of representation, and also by concerns for efficient handling of data structures. This 
machine would not naturally be constructed by the naive strategy we have presented 
without a better understanding of architectural concerns. We believe, however, that the 
techniques we have developed could be adapted to prove the correctness of the FAM 
relative to an operational semantics for the core subset of ML that it implements. 

Our use of operational semantics as the basis for language definitions supports a sim- 
ple means for describing both semantics and machines in a single framework, namely 
proof systems. This uniformity contributes to the simple construction and verification of 
machines from semantics. In addition, operational semantics provides a natural setting 
for explicitly separating static and dynamic semantics. An alternative approach to lan- 
guage definition and implementation uses denotational semantics to define languages but 
also uses abstract machines as an implementation mechanism. One example of this ap- 
proach uses a two-level meta-language to distinguish between compile-time and run-time 
operations of a denotational semantics and translates the run-time operations into an 
intermediate-level machine code [NN88]. The abstract machine and compiler defined in 
this way, though strongly influenced by denotational semantics, are given informally, and 
a correctness proof is still required to relate the denotational semantics, target language 
semantics, and compiler. Unfortunately, this proof requires some complex mathematical 
machinery (e.g., Kripke-like relations) to define a relation between the denotations of 
programs and the actions performed by abstract machines. This complexity seems in- 
herent in this approach to compiler correctness due to fundamental differences between 
denotational definitions and abstract machine definitions. 

The distinction between compile-time and run-time operations provided by this two- 
level meta-language corresponds partly to the separation of operational semantics into 
distinct static and dynamic semantics specifications. In our work we have started with a 
dynamic semantics and not attempted to make any further distinction in the semantics 
regarding stages of operation. Thus our abstract machines operate on the same language, 
though perhaps in a different syntax, as the operational semantics. Additional separation 
of these abstract machines into compile-time and run-time operations, producing a level 
of machine code similar to that produced in the above approach, can be found in [Han91]. 

An alternative approach to constructing abstract machines from semantics is explored 
in [Wan82] where a continuation-style denotational semantics is used instead of opera- 
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tional semantics. The proposed technique involves choosing special-purpose combinators 
to eliminate A-bound variables in the semantics and discovering standard forms for the re- 
sulting terms, to obtain target code that represents the meaning of the source code. The 
resulting abstract machine interprets these combinators. This approach relies on heuris- 
tics to choose appropriate combinators and discover properties of these combinators. 
Verification of the abstract machines constructed using this method is not addressed. 

Finally, all the proof systems used in this paper can be naturally represented in the 
dependent type system LF [HHP87]. It is then possible to use the Elf implementation 
[Pfe91] of LF to implement the various transformations we have presented. Initial work 
in this direction is reported in [HP92]. 

8. Summary 

We presented a general method for translating the operational semantics of evaluators 
into abstract machines. We believe that the choice of operational semantics as a starting 
point for semantics-directed implementations of programming languages is advantageous 
as it provides both a high-level and natural specification language and, as argued here, 
can be translated into intermediate architectures found in real, hand-crafted compilers. 
Though not automatic, our method provides a flexible approach for designing represen- 
tations of languages that are suitable to machine implementation. 

The translation from operational semantics to abstract machine proceeds via a series 
of transformations on the operational semantics. These specifications are given by proof 
systems axiomatizing evaluation relations, and the proofs constructible in these systems 
provide concrete objects representing the computation steps performed during evaluation. 
By examining the structure of these proofs, we can identify properties (of proofs and/or 
the proof system) that allow us to transform the proof system and also the proofs. 
Because proofs are syntactic objects that can be encoded as terms in a logic, we believe 
that most of the manipulations described here can be performed by an automated system, 
providing, at least, machine checked proofs of the construction of abstract machines. 

Specifications within a second-order meta-logic can leave many aspects of computation 
implicit: implementations of the meta-logic must provide for such features as backtrack- 
ing, unification, stacking of goals, etc. The central goal of the transformations presented 
here has been to make some of these implicit aspects more explicit within the specifica- 
tion. Thus, as the transformations continue, fewer features of the meta-logic are required. 
In our examples, transformations are continued until the the meta-logic can be modeled 
using a simple, iterative rewriting system characterized here as an abstract machine. 

Appendix A. Unfolding Rules 

One common kind of transformation on inference rules is a simple unfolding of two rules, 
producing a single new rule. Let Rx and i?2 be two inference rules of the form 
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Fig. 25. Eliminating derived rules 

for n, m > 1, respectively, such that for some i, 1 < i < m, A and 5,- unify with unifier 
o\ Then the following rule, denoted as o-(Ri/ R.2)i, is a derived rule from Ri and i?2 : 

a(B l )---a(Bi-i) a(Ai) ■ ■ ■ a(A n ) <r(B i+1 ) ■ ■ ■ a{B m ) 

a(B) 

We call Ri and R2 the unfolded rules. We assume no clashes of the universally quantified 
variables occurring in these terms, as these variables can always be renamed. Note that 
for two given inference rules, a number of derived rules can exist based on possible choices 
of i and a. 

Theorem 20. Let £ be a proof system including two rules R\ and R2 with c(i?i/.R2)« 
a derived rule for some a and i. Then for all formulas A, £ h A if and only if £ U 
{a(R 1 /R 2 ) i } h A. 

Proof. The proof in the forward direction is trivial as any £ proof is also a £ U 
{o-{R\/ R2)%) proof. In the reverse direction we show that for any A and any £ U 
{cr(Ri/R2)i} proof of A all occurrences of <r(i?i/i?2)« can be replaced by instances of 
Ri and R2. Assume Ri, R2, <r, i and f(i?i/i?2)< are as described above. Now let II 
be any £ U {<r (Ri/R2)i} proof containing some instance of o~{R\/R2)i and let E be a 
subproof of II whose last inference rule is an instance of cr(i2i/i?2)i- This subproof must 
be of the form (*) in Figure 25 for some substitution 0. Since cr(5») equals o~(A), we 
can construct another proof S' of 0(o-(B)) that contains one less instance of cr(Rx/R2)i 
as given by (t) in Figure 25. Repeating this process until there are no more instances of 
o-(Ri/R 2 )i yields an £ proof. □ 

While it is not generally true that the inference rule cr(Ri/R2)i can replace R\ and 
R 2 , such replacement is possible at several points in this paper. When this is possible, 
we need to show that in any proof using Ri and R 2 , these two rules occur together (as 
illustrated above) and hence can be replaced by instances of the unfolded rule (setting a 
to the most general unifier, in this case). 

Appendix B. Factoring Inference Rules 

Call a proof system deterministic if for any provable proposition there exists a single 
(normal) proof of that proposition. Proof systems specifying the evaluation of functional 
programs usually are deterministic. Unfortunately, this property does not necessarily 
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imply that the naive bottom-up construction of proofs is free from backtracking. For 
example, a bottom-up strategy may need to backtrack because for a given proposition, 
multiple inference rules may be applicable, even though only one can eventually lead to 
a proof. 

We consider a class of proof systems for which bottom-up proof search requires back- 
tracking, and we describe a transformation that effectively removes the need to backtrack. 
Our transformation is closely related to the factorization of context free production rules 
with common initial segments, and it has also been examined in [Sil90]. The following 
transformation can be used in conjunction with other transformations to remove the 
need for backtracking in some proof systems. For notational convenience we abbreviate 
<*! :: • • • :: a n :: C as a @ C. 

Factoring Transformation. Let £ be a proof system in which every non-axiom infer- 
ence rule is of the form 

prove a' @C 8' 
prove a : : C 8 

where C is either nil or a meta-variable. Furthermore, assume £ has a pair of rules of 
the form 

/ prove a'@p@C 8' prove a'@y@C 8' \ 

I prove a ::C 8 prove a ::C 8 J 

for some terms a, a', f3, j, 8 and 8'. Let £ c be a proof system that contains the following 
three classes of inference rules: 

1 For a new, fixed constant choice, the two inference rules 

prove d@C Z prove C 2 @C Z 

prove (choice C\ C 2 ) ::C Z prove (choice C\ C 2 ) v.C Z 

are members of £ ch . Here, Z, C, C\, and C2 are schema variables for both of these 
rules. 

2 For each pair of rules of the form displayed above, add to £ e the inference rule 

prove a' @ (choice (i 7) :: C 8' 
prove ctv.C 8 

3 Finally, every inference rule of £ not in such a pair is added to £ ch . 

This transformation provides a means for delaying a choice between two inference rules 
(during bottom-up proof construction) until after their common initial segment (a) has 
been "processed." 

Theorem 21. Let £ ch be obtained from some system £ as given by the Factoring Trans- 
formation above and let (prove a 8) be a closed proposition containing no occurrences 
of choice. Then £ h (prove a 6) if and only if £ ch h (prove a 8). 

The proof is by a straightforward induction on the height of proofs. 
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